Comment 3 for bug 1576308

FYI, this would allow gsettings to be used:

# Unrestricted access to gsettings. This is an information leak and allows
# tampering with settings from other apps. This will be fixed when
# gsettings/AppArmor mediation is completed.
#include <abstractions/dconf>
owner /{,var/}run/user/*/dconf/user w,
owner @{HOME}/.config/dconf/user w,
dbus (receive, send)
    bus=session
    interface="ca.desrt.dconf.Writer"
    peer=(label=unconfined),

However I'm not excited about adding that to the policy for the reasons stated in the comment. I'm aware of gsettings and apparmor mediation that would fix this and perhaps it can be prioritized for 16.10 (pending stakeholder process) and eventually SRUd, but if we allow this now and apps use it we can't easily undo it.

The applications appears to without it even though there are many denials. Have you considered:
* I know dconf has multiple backends-- is it possible to use a different backend
* have dconf use SNAP_USER_DATA as the prefix instead of HOME
* set HOME to SNAP_USER_DATA as part of the 'calc' wrapper script?