RDPlot is a tool for analysis of scientific data often generated by some HPC cluster. Therefore, the data is often stored on networkdrives mounted in other locations than /home. For this reason it would be good, if access to all directories would be granted.
is there any reason these dirs could not be mounted under /media and your snap using the removable-media interface ?
For sure they can but changing all default paths and configuration will have many side effects for our institute. I think this is more or less a common issue. We are most probably not the only ones mounting an NFS drive to /someNameOfTheDrive.
there is some work to support mounts in /mnt instead of /media with a new interface:
but i doubt we’ll support random access to / or /randomname in the near future …
OTOH i’m not sure this qualifies the snap to become classic either, since you can actually use it strictly confined if you set your system up differently …
Alright, I am pretty aware of the fact that we do not need the classic confinement in order to reach our goals. However, as already mentioned it is not practical at all to setup the system differently and just be searching the web I ended up at other posts reporting issues like that. So, the final question is: Is it possible to make the snap classically confined or will that not happen. In case 2, I think we will need to stay with other deployment strategies.
By design, snaps run in a sandbox with a predictable runtime and filesystem layout. Classic snaps of course are not confined and can access anything on the host. Allowing arbitrary access to anywhere in the filesystem (which is why you asked for classic) defeats the purpose of the confinement (which is why we limit its use) and it sounds like the snap would run just fine with or without the home and removable-media interfaces. AFAICS, the issue here isn’t so much about the snap, but about your site’s infrastructure and therefore it would be inappropriate to grant the snap itself classic for this reason alone.
While there is some support for NFS home, snapd does not currently handle arbitrary NFS mounts out of the box. Today you can work around the limitation by performing a bind mount from the NFS mount into somewhere allowed by the home or removable-media interfaces. This can be made automatic via systemd (which can create the necessary dirs under /media). Eg:
$ cat /etc/systemd/system/mount-into-rdplot.service
[Unit]
Description=Mount unit for mounting NFS for rdplot into in /media
Before=snap.rdplot.rdplot.service
[Service]
Type=oneshot
ExecStart=/bin/mkdir -p -m0755 /media/rdplot/stuff
ExecStart=/bin/mount --bind /srv/your/nfs/mount/dirs /media/rdplot/stuff
ExecStart=/bin/mount -o remount,bind,ro /media/rdplot/stuff
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Unless I am missing something, this shouldn’t change any configuration-- NFS exports to the same places, it is just that rdplot needs to look in the correct place, which it has to anyway because it is a snap. Perhaps you could use a symlink in your NFS tree to point into the bind mounts in /media or use an environment variable that alerts rdplot to prepend /media/some/where before the root of your forest of NFS mounts. There are of course various ways of doing this, but the point is, make the mounts available in /media somehow and then point rdplot there.
snapd could perhaps make this easier for you with an additional command, but then you’d still need to run that command to give the snap access (just like today you need to run a command to perform the bind mount), which would be site-local and not significantly different from the above (though is a usability improvement).
On the roadmap is a new interface that we’ll create that will allow specifying arbitrary paths, but this interface wouldn’t be appropriate for the rdplot snap that anyone could use, because it would be encoding site-specific information into a snap meant for everyone.
Since you mentioned your ‘institution’, you might also consider a brand store where you can control and limit what is in your store to your institution. There might be some limitations on this today if your cluster is a classic distribution, but the store team can advise on that.
Hope this helps!
Alright, I am going to accept this and marking the answer as solution.