I am in a situation where a snap package has to access files which are stored on a remote file system share (mounted at “/nfs”). I see there is currently no “clean” way to achieve this. For some time, I could help myself with “bind” mounting stuff below the “/media” folder, that would enable access. For some reason this has stopped working reliably. I typically get this error when starting my application:
“cannot open path of the current working directory: Permission denied”
My snap package is currently in devmode. This is both what is defined in snapcraft.yaml and during snap install, which I do with “–dangerous --devmode” options.
…and to me this implies that my package should be able to access the filesystem. What am I doing wrong?
Note that “classic” confinement is not an option for me, because I cannot have non-snapped shared libraries interfere with it. Currently for me, the point for snap is more the “run everywhere” part, and I am not concerned so much about security.
The snap runs in its own mount namespace that’s not shared with the host. devmode opens up permissions, but can only see what’s available in the namespace.
If you have nfs mounted under /media, perhaps you need to connect the removable-media interface?
You could also consider using personal-files or system-files depending on your use case for your snap (and your users).
You should try installing with just--devmode, not both --dangerous and --devmode as --dangerous turns on confinement and --devmode is supposed to turn it off, so it seems that we should probably add some code to make snap install “do what you mean” and use the --devmode confinement being off to overwrite the --dangerous leaving it on.
Also to be clear,
snap install ... --dangerous installs with confinement turned on, but with the check for a matching snap-declaration turned off. The snap-declaration is what contains things like the revision number, any auto-connects you might have, etc.
snap install ... --devmode installs with confinement turned off (well in “complain” mode mostly), but also with the check for a matching snap-declaration turned off.
The snap runs in its own mount namespace that’s not shared with the
host. devmode opens up permissions, but can only see what’s available in
the namespace.
Ok.
If you have nfs mounted under /media, perhaps you need to connect the
removable-media| interface?
Should this in the snapcraft.yaml give app “auto-mask” access to things
below /media and $HOME?:
apps:
auto-mask:
plugs:
- home
- removable-media
Sorry, this is probably obvious but I am a bit confused when things have
to be declared. During build (snapcraft)? During install? Or later via
manually connecting interfaces?
Do devmode packages have access to all “slots” in the system?
Is it possible to extend things manually after install if something was
forgotten in the snapcraft? Or can it only be further restricted?
You could also consider using |personal-files| or |system-files|
depending on your use case for your snap (and your users).
Yes, this looks interesting. Shouldn’t it be possible (I understand it
is not adivsable) to give access to a whole mount point (like /nfs in my
case) via system-files?
I think the error here is that when --dangerous and --devmode are used together, --devmode should “win” and apply instead of --dangerous. Then the help messages and the expected flow makes the most sense.
