Snap layouts

doc
32

is there a “best practice” advice of when to use bind-file or bind vs symlink? i.e. when would we prefer to use a symlink over binding and vice versa?

33

Symlink is generally more light-weight and unlike a bind mount, can be removed by the application when used in locations such as $SNAP_DATA. Applications more commonly identify symlinks-vs-regular-files than they do with bind mounts so you may need to use a bind mount to convince a picky application to use something but in general symbolic links should be preferred simply because they are cheaper.

2 Likes
34

Hello @zyga-snapd, what i understand is Layout will bind the “$SNAP_DATA/etc/foo.conf” file with the host “/etc/foo.conf” path, maybe you can correct my understanding here.

My question is how i can place foo.conf file in $“SNAP_DATA/etc/foo.conf” path ?

For now, what I am doing is, I wrote a cp command which will copy the foo.conf file from “$SNAP/etc/config.conf” to “$SNAP_DATA/etc/foo.conf” in configure file of hooks dir that will be executed while installing the snap.

Does Layout will do the above task?

35

You cannot put the file in $SNAP_DATA/anything before the snap gets a chance to execute but on the upside the layout will actually create the file for you. All hooks, even install and configure run after the snap layout has been constructed.

EDIT: so to make it clear, you can just write to the file that was placed there by the layout system.

36

A post was split to a new topic: Python3 application with external module

37

12 posts were split to a new topic: Building with snapcraft in docker

38

It would be nice if it were documented that layouts were not supported in classic containment.

2 Likes
39

Thanks for bringing this up, and you’re absolutely right. We should have made it completely clear that layouts won’t currently work with classic. I’ve changed the first line to hopefully make it clearer and I’ve added a caveat to the limitations section.

1 Like
40

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

So, what is the way out?

41

fixig snappy-debug to not suggest layouts for /run paths …

1 Like
42

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
43

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
44

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.

45

i’d rather say redundant :slight_smile: what is contradictory about it ? it just re-states the same thing in different words …

46

The directory names differ.

47

hah, blind me … sorry :slight_smile:

48

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
49

Can this page show a legitimate example for symlink:?

50

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).

51

Thanks for letting us know, and for the detailed comment. I’ll take a look over this doc and update it.