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?
** Changed in: snapd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1576308
Title:
gsettings doesn't work with snap confinement
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576308/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
