Using snapd-glib to configure core watchdog I need to talk to snapd using /run/snapd.socket. When I did that, Snappy debug complains about DENIAL for using /run/snapd.socket and suggested to make use of layouts
= AppArmor =
Time: Apr 25 14:00:10
Log: apparmor="DENIED" operation="connect" profile="snap.plt.wtdog.runner" name="/run/snapd.socket" pid=1605 comm="setpet" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
File: /run/snapd.socket (write)
Suggestions:
* adjust program to use $SNAP_DATA
* adjust program to use /run/shm/snap.$SNAP_NAME.*
* adjust program to use /run/snap.$SNAP_NAME.*
* adjust snap to use snap layouts (https://forum.snapcraft.io/t/snap-layouts/7207)
But the post here mentions /run path cannot be used. I tried it anyway using: layout: /run/snapd.socket: bind-file: $SNAP_DATA/snapdsocket
But, get an error: layout "/run/snapd.socket" in an off-limits area
To talk to the snapd.socket use the appropriate interface (snapd-control). Using layouts for that is a mistake and snappy debug should not be suggesting that.
Well, snappy-debug is trying to make suggestions based on what it sees, it has no idea what the snap is trying to do. A layout is a valid suggestion for many /run paths. It is not for /run/snapd.socket though, and I’ll adjust it for that.
(As an aside, snappy-debug typically does not recommend plugging super-privileged interfaces which is why snapd-control was not suggested).
During some investigation we’ve discovered that this doc is out of date. Specifically, there are some additional paths which are verboten: /lib/firmware and /lib/modules. See the code block here.
What’s interesting about this is that you can trivially work around it; if you modify your layout from being /lib/{firmware,modules}/foo to /usr/lib/{firmware,modules}/foo, you can distribute this snap just fine (not certain if it works, but snapcraft will no longer complain when building the snap).
What I think is even more interesting is that you can probably do what this layout restriction is trying to guard against (namely, replacing all of /lib/firmware or /lib/modules with some arbitrary directory/file) anyways by simply prepending /usr to your layout as above, which I think is a bug (considering /lib -> usr/lib).
I might point out that since /lib -> usr/lib, just listing, say, /usr/lib/firmware might not be enough explanation since a lot of people think of firmware as being under /lib/firmware, and the new tests cover both /lib/firmware and /usr/lib/firmware. Make it clear that the restrictions cover both of those possibilities, so you can’t do and end-run around them anymore.
What I might do in that list is pair up symlink-associated directories, like this (leave the rest of the entries as is):
/lib/firmware, /usr/lib/firmware
/lib/modules, /usr/lib/modules
/run, /var/run
Then, right after the list, explain that those pairs of entries are because of symlinks that make them effectively equivalent so they both need to be restricted. I think this is clearer than having those paired entries separated by several intervening entries in the list.