Long-running processes start getting apparmor denials after refresh

[laney]

I was chillaxing, max relaxing at my desk yesterday when I started to be spammed with notifications from aa-notify about Spotify being denied various things. A sample from dmesg:

[Tue Feb 18 09:16:03 2020] audit: type=1400 audit(1582017346.757:15155): apparmor="DENIED" operation="mknod" profile="snap.spotify.spotify" name="/home/laney/snap/spotify/36/.config/spotify/Users/laney-user/pending-messages.tmp.8" pid=436311 comm=436F726520546872656164 requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
[Tue Feb 18 09:16:03 2020] audit: type=1400 audit(1582017346.757:15156): apparmor="DENIED" operation="mknod" profile="snap.spotify.spotify" name="/home/laney/snap/spotify/36/.config/spotify/Users/laney-user/pending-messages.tmp.9" pid=436311 comm=436F726520546872656164 requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
[Tue Feb 18 09:18:25 2020] kauditd_printk_skb: 94 callbacks suppressed
[Tue Feb 18 09:18:25 2020] audit: type=1107 audit(1582017489.450:15251): pid=3131 uid=102 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="state" mask="send" name=":1.19" pid=3361009 label="snap.spotify.spotify" peer_pid=3134 peer_label="unconfined"
                            exe="/usr/bin/dbus-daemon" sauid=102 hostname=? addr=? terminal=?'
[Tue Feb 18 09:18:39 2020] audit: type=1107 audit(1582017503.090:15252): pid=3131 uid=102 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="state" mask="send" name=":1.19" pid=3361009 label="snap.spotify.spotify" peer_pid=3134 peer_label="unconfined"

Several of these per second whenever it tried to do anything other than continue playing a track - e.g. change to the next track (show a notification — which it couldn’t do any more).

Now I can see from snap changes that there was indeed a refresh yesterday:

590  Done    yesterday at 13:06 GMT  yesterday at 13:08 GMT  Auto-refresh snap "spotify"

And indeed the spamming went away when I restarted the application.

Was it that the apparmor profiles for the old version stopped working after the refresh? I can see a revision-specific directory in there and @jamesh told me that access to these goes away when the new revision’s profiles get installed so I guess this is right and the D-Bus denials could be another instance of the same thing?

I’ve heard about refresh awareness - is the snapd position that applications need to implement this and they may be (subtly or not so) broken after a refresh and before a restart? Or is it possible to do something better here and wait until launching the new revision before applying its apparmor profiles somehow? Any plans to share? Pointers to existing discussions, plans or documentation gratefully welcomed of course.

laney@raleigh> snap --version
snap    2.43.2
snapd   2.43.2
series  16
ubuntu  20.04
kernel  5.4.0-12-generic

[jamesh]

The denied mknod calls would fail under both the new and old policies. Presumably this is a code path that likely failed only gets run in an error code path? Perhaps when it loses write access to /home/laney/snap/spotify/36?

For the denied D-Bus method calls, that is controlled by the network-manager interface. It looks like there is a spotify:network-manager plug, but nothing in the snap declaration would cause it to auto-connect (and it’s not clear it’d be appropriate: if it’s just after a connectivity check it would be good to push them towards the portal APIs).

[laney]

@jamesh

The denied mknod calls would fail under both the new and old policies. Presumably this is a code path that likely failed only gets run in an error code path? Perhaps when it loses write access to /home/laney/snap/spotify/36 ?

That could be right. But then it is an indirect indication of a problem: we got refreshed and now something doesn’t work any more, so we’re trying a fallback path and luckily(!) that is denied so it’s noticed more easily. The issue is still that refreshing broke something in the running application.

@jamesh

For the denied D-Bus method calls, that is controlled by the network-manager interface. It looks like there is a spotify:network-manager plug, but nothing in the snap declaration would cause it to auto-connect (and it’s not clear it’d be appropriate: if it’s just after a connectivity check it would be good to push them towards the portal APIs).

No educated comment on this; I’m sure what you’re saying is right but then can’t explain it correlating with the auto-refresh. Maybe it has multiple ways to check connectivity and one of them broke and the fallback one isn’t connected so doesn’t work?

[ogra]

[WIP] Refresh App Awareness

This thread summaries an upcoming feature of snapd that is something many application developers were asking for a long while now. Internally we call it refresh-app-awareness because it means snapd is aware of running applications and will inhibit refreshes of snaps with apps running. The feature is smart enough to filter out services that are restarted during refresh. Current Status The feature is currently under development, coming to snapd 2.39 behind a feature flag, that is, it will require…

might improve this …

[ilgazcl]

A Google search for Spotify not launching fine under Ubuntu 22.04 has leaded me to this topic. On our laptop we use Spotify for music and when it auto launches after boot (added to desktop startup) it shows a blank window with

kernel: audit: type=1107 audit(1689149320.995:262): pid=1283 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor=“DENIED” operation=“dbus_signal” bus=“system” path="/org/freedesktop/NetworkManager" interface=“org.freedesktop.NetworkManager” member=“CheckPermissions” name=":1.9" mask=“receive” pid=3907 label=“snap.spotify.spotify” peer_pid=1290 peer_label=“unconfined”

in journal. However, when you close the application and launch again, it works fine. I wonder if it is related to timing, e.g. snap not initilizing fast enough to setup permissions etc.