@matthijs (Matthijs Kooijman) posted a new topic, subject "Apparmor-related denials for Spotify snap". It read:

   I'm running the Spotify snap (version 30.227-07-0647.g416cacf1, snapd 2.48+20.04 on Ubuntu 20.04), and noticed repeated apparmor audit messages for stuff that was denied. I understand that snapd generates this policy based on the snap metadata, so I'm wondering where these should be fixed (by silently denying them, or allowing them)? Iow, should I report a bug with Spotify and if so, what should I tell them?
    
    The errors are:
    [code] 
        [960286.727553] audit: type=1400 audit(1607100224.709:35211):
                        apparmor="DENIED" operation="open"
                        profile="snap.spotify.spotify"
                        name="/home/matthijs/.config/xdg-templates/" pid=3220240
                        comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
        [960291.908537] audit: type=1400 audit(1607100229.889:35212):
                        apparmor="DENIED" operation="open"
                        profile="snap.spotify.spotify"
                        name="/home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled"
                        pid=3220144 comm="spotify" requested_mask="r"
                        denied_mask="r" fsuid=1000 ouid=1000
        [960293.920460] audit: type=1107 audit(1607100231.901:35213): pid=1513
                        uid=105 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.6549" pid=3220144
                        label="snap.spotify.spotify" peer_pid=1173777
                        peer_label="unconfined" exe="/usr/bin/dbus-daemon"
                        sauid=105 hostname=?  addr=? terminal=?'
        [961133.425258] audit: type=1107 audit(1607101071.403:35231): pid=1513
                        uid=105 auid=4294967295 ses=4294967295
                        msg='apparmor="DENIED" operation="dbus_signal"
                        bus="system" path="/org/freedesktop/NetworkManager"
                        interface="org.freedesktop.NetworkManager"
                        member="CheckPermissions" name=":1.6549" mask="receive"
                        pid=3220144 label="snap.spotify.spotify"
                        peer_pid=1173777 peer_label="unconfined"
                        exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=?
                        terminal=?'
        
    [/code]
    
    The error for `/home/matthijs/.config/xdg-templates/` sounds like it would be fixed by including `abstractions/xdg-desktop`, which I thought contains a blanket allow for `~/.config` and `~/.local`, so would fix the `/home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled` error as well. But it doesn't work here, so maybe the allow in that file is just for listing those directories, rather than accessing things under them, and explicit rules should be added? These error messages only happen once when starting spotify, so they're not too annoying (and Spotify probably doesn't really need either of these files, so no harm done).
    
    Note that I _think_ both of these files are not common, I suspect most people will not have either of them, so most people probably wont' see these.
    
    As for the `NetworkManager` dbus calls, it seems Spotify calls to dbus to get network information, which is not allowed. Is that something that must be explicitly enabled in the snap? Or should this be added to the default profile in snapd maybe? These seem to happen more often (seems they happen when devices are added or remove, i.e. USB devices), so are annoying in the log and having access to the network state might be actually useful to Spotify as well.
    
    I've now fixed this locally by adding these rules to ``, but that will of course be overwritten on an update, so I'd rather get this fixed properly.
    [code] 
        dbus (send,receive)
             bus=system
             path="/org/freedesktop/NetworkManager"
             interface="org.freedesktop.NetworkManager"
             member="{CheckPermissions,state}",
        
        owner @{HOME}/.config/xdg-templates/ r,
        owner @{HOME}/.local/share/glib-2.0/schemas/gschemas.compiled r,
        
    [/code]

To which @ogra (Oliver Grawert) replied

    looks like not all interfaces are connected … check with
    [code] 
        snap connections spotify
        
    [/code]
    
    if after connecting there are still errors, you can use the snappy-debug command from the `snappy-debug` snap, run it in a terminal while running the app and see if there are any suggestions … if there are still remaining denials that do not come with suggestions, thats likely a bug (either in spotify or likely a missing/inclomplete interface in snapd)

@matthijs (Matthijs Kooijman) replied

    Thanks for the useful suggestions.
    
    There was indeed an open `:network-manager` connection, all others seem to have been autoconnected. Connecting that indeed fixes the audit errors. However, I do wonder:
    
      * If Spotify only queries the network state, it would be more appropriate for it to declare `network-manager-observe`, to not allow access to modify the network config? I tried connecting the existing `network-manager` plug to the `:network-manager-observe` slot, but as expected that doesn't work.
      * Even if Spotify might in some cases modify NM settings (i.e. add port forwards or QOS settings or whatnot), I suspect it might be appropriate for the snap to declare both a `:network-manager` and `:network-manager-observe` plug and allow the user to decide how much access to grant.
      * I see `:network-manager-observe` is also not autoconnected, even though that seems like a fairly harmless permission. Is there any documentation about such a decision?
      * If such an interface is _not_ connected, wouldn't it make sense to add explicit (silent) deny rules rather than deferring to the default (noisy) denial for these requests? Or is a snap that declares such an interface expected to ask snapd whether the interface is connected and if not, refrain from making these requests?
      * Would/should the installation of this snap have asked me about making this connection? I can't recall, but I think it didn't ask (though the “software” GUI tool on this Ubuntu system stopped working (keeps loading indefinitely), so I can't check there now).
    
    
    
    For the file accesses, `snappy-debug` says:
    
      * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
      * add ‘personal-files (see https://forum.snapcraft.io/t/the-personal-files-interface for acceptance criteria)' to ‘plugs'
    
    
    
    But I'm not sure how appropriate these are. Adding `personal-files` seems overkill, since I _suspect_ spotify is not actually accessing files, just letting GTK/Glib or some other library do its default initialisation (which probably also complicates applying the first suggestion). I could report a bug, but as I said, these are not quite that annoying and probably don't apply to 99% of the users, so I think I'll let these slide.

After which, @ogra (Oliver Grawert) added

    matthijs:
    
    > For the file accesses, `snappy-debug` says:
    
    could you paste the lines before and after as well ? just seeing the errors without any context does not help a lot

@matthijs (Matthijs Kooijman) replied

    Oh, that's just the error messages from dmesg that I previously posted. But here's the complete output from `snappy-debug`:
    [code] 
        INFO: Following '/var/log/syslog'. If have dropped messages, use:
        INFO: $ sudo journalctl --output=short --follow --all | sudo snappy-debug
        
        
        = AppArmor =
        Time: Dec  5 12:55:53
        Log: apparmor="DENIED" operation="open" profile="snap.spotify.spotify" name="/home/matthijs/.config/xdg-templates/" pid=3354443 comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
        File: /home/matthijs/.config/xdg-templates/ (read)
        Suggestions:
        * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
        * add 'personal-files (see https://forum.snapcraft.io/t/the-personal-files-interface for acceptance criteria)' to 'plugs'
        
        = AppArmor =
        Time: Dec  5 12:55:53
        Log: apparmor="DENIED" operation="open" profile="snap.spotify.spotify" name="/home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled" pid=3354352 comm="spotify" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
        File: /home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled (read)
        Suggestions:
        * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
        * add 'personal-files (see https://forum.snapcraft.io/t/the-personal-files-interface for acceptance criteria)' to 'plugs'
        
    [/code]

After which, @ogra (Oliver Grawert) added

    aha … i wonder if the desktop interface should be extended to allow read access of these … or if we dont want this if the apparmor complaints could be quietened … perhaps the @security team could chime in here …

Then @Wolff (Wolff) said

    I don't know if it's that though, but I couldn't find anything else on the Internet about it, that's why I come here Krogerfeedback
    
    Just in case these are the snap packages I have installed:
    
    > core
    > 
    > core18
    > 
    > gnome-3-28-1804
    > 
    > gtk-common-themes
    > 
    > quake-toolkit
    > 
    > snapd
    > 
    > trenchbroom
    
    Please help!
    
    Edit: This also happens when I try to run any snap (tried with quake-toolkit tools).
    
    5 Comments

To which @ogra (Oliver Grawert) replied

    this is neither related to the sporitfy app nor to the apparmor denials listed above, could you please open a new thread (and attach the output of `snap version` there, along with `snap debug confinement` and `snap debug sandbox-features` ) ?


{'source': 'discourse', 'url': 'https://forum.snapcraft.io/t/apparmor-related-denials-for-spotify-snap/21479', 'title': 'Apparmor-related denials for Spotify snap', 'views': 1239, 'has_accepted_answer': False, 'word_count': 1405, 'like_count': 0, 'reply_count': 3, 'participant_count': 3, 'posts': 8, 'tags': '', 'author': '@matthijs (Matthijs Kooijman)', 'participants': '@matthijs (Matthijs Kooijman), @ogra (Oliver Grawert), @Wolff (Wolff)', 'image_url': [None], 'created_at': '2020-12-04T17:32:01.254Z', 'last_posted_at': '2020-12-05T13:31:52.238Z'}