Hi, On our team we've been working to snap the thumbnailer project. While there are some problems that are probably specific to this package, there were a few that I suspect might affect other packages too:
1. Intra-snap D-Bus communication The thumbnailer D-Bus service exposes a number of methods that were intended for use by the "thumbnailer-admin" helper program, but not by outside clients. The generic "dbus" snappy interface does a good job of making sure clients can't call these privileged methods, but I'm left needing a way to get thumbnailer-admin working again. I noticed that the default AppArmor rules allow communication via unix domain sockets with other apps from the same snap, so one easy way to solve my problem would be to also allow applications to send and receive arbitrary messages over the session bus to/from other applications from the same snap. This would let me get thumbnailer-admin working without having to expose the same abilities to third party snaps through a slot. I filed a bug about this one here: https://bugs.launchpad.net/snappy/+bug/1659724 2. Use of the libapparmor aa_is_enabled and aa_query_label APIs When deciding whether to do work on behalf of a client, thumbnailer-service uses a couple libapparmor API calls to determine whether the client has access to a file. Neither of these are working under snappy confinement. The first call we use is aa_is_enabled(), but it seems the policy is to strict to let us determine whether AppArmor is enabled or not. Next we use aa_query_label() to perform the file access check. This fails when trying to read /proc/$pid/mounts to determine where securityfs is mounted. If that is fixed, it will likely fail when trying to access the "/sys/kernel/security/apparmor/.access" file within. I've filed a bug for this one here: https://bugs.launchpad.net/snappy/+bug/1660957 3. QNetworkAccessManager wants to access NetworkManager We use QNetworkAccessManager as our HTTP library. This results in a number of denials for D-Bus method calls to NetworkManager. I can make these denials go away by plugging in to the ":network-manager" slot, but a quick look at that interface shows that it grants a lot more permissions than I need or want (i.e. permission to reconfigure the network). I imagine that a lot of snaps will use QNetworkAccessManager, so it would be nice if the calls it makes were allowed by some auto-connectable interface. If not as part of ":network", then something similar. James. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft