Apparmor denial in new snap-store despite connected packagekit-control interface

Hi everyone,

I’m investigating this issue with the new snap-store:

We’re getting apparmor denials

May 24 13:14:22 - audit[1964]: USER_AVC pid=1964 uid=102 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/PackageKit" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.freedesktop.PackageKit" pid=285422 label="snap.snap-store.snap-store"
                                     exe="/usr/bin/dbus-daemon" sauid=102 hostname=? addr=? terminal=?'

when running the application while packagekit.service is inactive. As far as I understand it terminates automatically after being idle for a while since the systemd service runs with Type=dbus, and it should automatically be re-activated when calling its DBus API. However, this doesn’t work from within the snap environment, even though packagekit-control is connected:

$ snap connections snap-store | grep packagekit-control
packagekit-control       snap-store:packagekit-control       :packagekit-control             -
$ systemctl is-active packagekit.service 
$ snap run --shell snap-store
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

$ dbus-send --system --print-reply --dest=org.freedesktop.PackageKit /org/freedesktop/PackageKit org.freedesktop.DBus.Properties.GetAll string:"org.freedesktop.PackageKit"
Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.1850" (uid=1000 pid=288251 comm="dbus-send --system --print-reply --dest=org.freede" label="snap.snap-store.snap-store (enforce)") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination="org.freedesktop.PackageKit" (bus)

The same happens with the snap-store in latest/stable, although running the actual application does re-activate the packagekit daemon, so something must be different there.

There are no denials when packagekit.service is already active. I’ve tested this on 22.04 and 23.10. Here’s the snapcraft.yaml.


P.S. After some more trial and error I found that I can activate the packagekit daemon from within the snap environment by running

dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.StartServiceByName string:org.freedesktop.PackageKit uint32:0

I don’t think this is the intended way, but it’s at least a workaround.

1 Like


turns out invoking StartServiceByName is what gnome-software does as well and changing the packagekit-control interface to allow for implicit service activation is currently not planned. See for details.