snapd-generator: set standard snapfuse options when generating units for containers #9613
Conversation
…ers in snapd-generator.
stolowski
changed the title
| @@ -185,7 +185,7 @@ int ensure_fusesquashfs_inside_container(const char *normal_dir) | |||
| fprintf(stderr, "cannot open %s: %m\n", fname); | |||
| return 2; | |||
| } | |||
| fprintf(f, "[Mount]\nType=%s\n", fstype); | |||
| fprintf(f, "[Mount]\nType=%s\nOptions=nodev,ro,x-gdu.hide,allow_other\nLazyUnmount=yes\n", fstype); | |||
There was a problem hiding this comment.
Do we have a link to the code before this was a generator and what options we set back then?
There was a problem hiding this comment.
It is spread over systemd.go (see mountUnitTemplate and fsMountOptions) and fstype.go in a bit convoluted way; I've copied them from mount options of a manually installed snap inside the container.
There was a problem hiding this comment.
this will be applied to all types, yet i thought in gocode the "allow_other" at least is scoped to fuse mount types only.
I somehow expected something like if strcmp() ==0 || strcmp == 0 to fprintf(",allow_other)" or some such (pseudo code).
Or it is safe to always pass allow_other?
It would be nice if the test would be somehow interactive.... can we compare the generated units in /run/systemd/generator with the ones in /etc/systemd/system ? Such that if and when mount options are changed anywhere in the gocode, the generator unittest fails due to any differences?
I guess as long as unit tests do run under lxd and non-lxd at least sometimes?
There was a problem hiding this comment.
@xnox this part of the generator is run for squashfuse/snapfuse only (fstype is either "fuse.squashfuse" or "fuse.snapfuse"). Both support "allow_other".
The idea for the test is nice, I'll see what I can do here or in a followup.
There was a problem hiding this comment.
So the extra test check (comparing Options of snapd-generator unit & snapd-generated unit) is possible and I'm working on it but fighting some issues around these checks, I think I'll leave it for a followup tomorrow, don't want to block this PR.
There was a problem hiding this comment.
Done in a followup #9617
| @@ -185,7 +185,7 @@ int ensure_fusesquashfs_inside_container(const char *normal_dir) | |||
| fprintf(stderr, "cannot open %s: %m\n", fname); | |||
| return 2; | |||
| } | |||
| fprintf(f, "[Mount]\nType=%s\n", fstype); | |||
| fprintf(f, "[Mount]\nType=%s\nOptions=nodev,ro,x-gdu.hide,allow_other\nLazyUnmount=yes\n", fstype); | |||
| VERSION_ID="$(. /etc/os-release && echo "$VERSION_ID" )" | ||
| lxd.lxc launch --quiet "ubuntu:$VERSION_ID" ubuntu | ||
|
|
||
| lxd.lxc file push --quiet "$GOHOME"/snapd_*.deb "ubuntu/root/" |
There was a problem hiding this comment.
we have some logic inside another script for setting up a container with the new snapd, is there a reason we're not using that here? I'm worried that for some reason something here will eventually need internet access inside the container and if we're not setting up the proxy it will fail, etc. or there will be issues installing the snapd deb here that are avoided with the workarounds in that script etc.
To be clear, this isn't a blocker, I'm just worried that this test might be a bit flaky without those extra things setup.
There was a problem hiding this comment.
The reason I didn't use that script (in fact I tried to add my checks first to existing lxd test, but then decided to add a new test) is it's a bit blunt and first purges snapd (and with that removes all snaps, e.g. core18 that come preseeded with lxd). I can add http_proxy logic here but I wasn't sure what is the expected use case for proxy?
There was a problem hiding this comment.
thanks for explaining that, makes sense now.
as to the proxy, I'm not sure, I always seem to see random lxd things fail around internet issues so I just implicitly assume that things in the container need internet access and as such setting up a proxy makes sense, but perhaps this case is straight forward enough it won't need a proxy setup at all.
Set standard snapfuse options (specifically, allow_other) in snapd-generator units for containers. If not set, the options from /etc/systemd/system/ mount unit is used, which in case of squashfs, doesn't have allow_other set.
For backgound: https://forum.snapcraft.io/t/cannot-locate-base-snap-core18-permission-denied/20796/19