fixig snappy-debug to not suggest layouts for /run paths …
1 Like
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.
3 Likes
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).
2 Likes
Early on:
“With layouts, you can make elements in $SNAP, $SNAP_DATA, $SNAP_COMMON accessible from locations such as /usr, /var and /etc.”
But later on page:
" <source-path> must refer to either $SNAP, $SNAP_DATA or $SNAP_USER_DATA."
That seems contradictory.
i’d rather say redundant 
what is contradictory about it ? it just re-states the same thing in different words …
Very good spot, thanks. I checked the original code and tests and it seems $SNAP_USER_DATA is a mistake. I’ve replaced it with $SNAP_COMMON. Thanks!
1 Like
Can this page show a legitimate example for symlink:?
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).
Thanks for letting us know, and for the detailed comment. I’ll take a look over this doc and update it.
The recent refinement of layout restriction: https://github.com/snapcore/snapd/commit/71407d3fb10
Thanks so much for flagging this, and for linking to the diff - that made it a lot easier to add the new exceptions.
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.
Thanks for the insight. I’ve updated the doc, but feel free to tweak it if you think it can be made clearer/more explicit.
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.
1 Like
Awesome - and done, thanks so much.
This page does not explicitly say whether layouts apply to a snap’s hook scripts. Perhaps that should be clarified.
1 Like
Thanks for the hint. I’ve just tested this and updated the text.
Perhaps I’m not in the right doc area, but I would like a example about redirecting from ‘/home/username/Paks’ to ‘$SNAP/Paks’.