+++ This bug was initially created as a clone of Bug #101902 +++

Allison Lortie wants dconf to be able to give contained apps access to specific subtrees of the dconf object path tree, without giving them general access to dconf.

Currently, a contained app either has full read/write access to dconf, or no access. It should have read/write access to its own subtree(s) of dconf configuration space, and no access to the rest.

Allison suggested an API in which the dconf service creates a new *cursor* object, and asks dbus-daemon to open up access to that object for a particular container instance.

(If it was just about method calls, we could require dconf to implement this itself. However, dconf sends broadcasts, and we want to lock those down too.)

Snap developers suggested that the Containers1 API should be usable for MAC as well as for DAC. To support that, we might want to have this be an opt-in feature, where rules added by dconf or similar only take effect if the container manager has opted-in to "can grant access". (Or we might want to decide that Containers1 is DAC, and tell Snap developers that if they want MAC they need to stick to AppArmor.)

[ ] New message filtering rules can be added by unconfined peers at runtime
[ ] Contained peers cannot alter message filtering rules
[ ] Peers can revoke exact access rules that they added (by making a method call with identically-matching parameters, or with a cookie that was returned when the rule was added, or something)

Out of scope
============

* Peers are not required to be able to revoke access rules by any more complex match rule than an exact one
* Peers are not required to be able to revoke access rules that were added at creation (the Allow parameter from Bug #101902), although it might also be acceptable if they can