@jdstrand I think they will understand it if they’re willing to put in the time (… they’re mostly well educated statistical geneticists after all), but I doubt that they want it. My goal with packaging it was to make the process easier rather than harder for them though and have it available in a more OS agnostic repository (which is why I didn’t go for more of a .deb or .rpm, etc…) that is properly tracked by a package manager.
Can you explain more about how to bind then, from the user’s perspective, if I can give them an easy line or two to do it then that’s probably good enough for me. Reading the docs I’m not really sure how to do this myself. I see this… Layouts: re-mapping snap directories but I’m not sure if it is finished and it seems that layouts are pre-specified locations from the developers side, where what I’m looking for is more of the opposite, arbitrary locations chosen by the user. When I say arbitrary, I just mean wherever their user could normally write to. The Docker way …works, but isn’t exactly elegant: https://hub.docker.com/r/kkunji/gigi2/ The reason we bother with it is in case it needs to be run on a larger scale, with Kubernetes on AWS or Azure for instance.
… oh wow, it works to bind mount some other random directory into home so long as you have a normal home. That should cover most use cases for users on their own (single user machines) though it is sort of unnecessarily cumbersome.
snap install opera
mkdir -p /home/username/mount_test
sudo bind -o /some/random/location /home/username/mount_test
Start opera and save stuff to /home/username/mount_test, exit opera
umount /home/username/mount_test
And the saved stuff is still at /some/random/location
Still we have corner cases: what if I need to write to another user’s subdirectory in an NFS based home for which they have modified file permissions so that I could normally write there (e.g. 775 and we’re in the same group)? This is a shared system, so we don’t have root, which is still fine for installing your own snaps, but bind-mounts require root. There are per user quotas on home size, which is the motivation for writing to a colleague’s home.
I see Snaps and NFS /home … but that seems like an outline for internal development, it isn’t at all clear to me what I can make use of now along those lines.
I’m not sure how it would defeat the purpose of strict confinement to allow a user to specifically override where the snap can write to for a single instance of the snap. Maybe there could be some kind of user override paradigm that prompts for permission from the user per use, ala like what sudo does when a user tries to run something that needs root. At least to me, it makes sense that a user should be able to allow an app to do anything the user is allowed to do. Not that that the app should be able to go off and do it without confirmation by default. Is there not a way to generalize something like the home or removable-media + network interfaces and to prompt asking for permission instead of just failing? I guess I don’t think of an application doing as it was told and writing to somewhere, e.g. /var/log when /var/log was specified for a log file output as “interfering” with the host system. If it did that without having been explicitly told to by the user, then I would agree with you.
Another case, we have a machine where I have root, but a number of other permissions are managed by a Domain Controller that I do not administer. I could install snapd, and then another user could install the GIGI2 snap… but our homes are on external NFS, e.g. /export/abc/ABCD/home/username I’m not sure how they could write data to their home in this case?
I know that NFS homes aren’t common in general, but they are very common on large shared clusters for scientific research that most users of my program likely do make use of.
Maybe some of these interfaces do something I don’t fully understand, frankly the documentation is pretty sparse. E.g.:
These are dangerously close to being tautologies, “storage-framework-service allows operating as, or interacting with, the Storage Framework.” … yeah… so what IS the “Storage Framework.”
“fuse-support allows access to FUSE filesystems.” Great, so what exactly do you include under “FUSE filesystems” Are all FUSE mounts supported? Trying to google for their relation with snap is also pretty useless. All I find while looking for the FUSE one is a few forum posts about how it perhaps does not work for SSHFS. The only way to find the actual information seems to be to search the in the forum Fuse-support plug and mount points in $SNAP_COMMON folder And it seems like there are plenty of caveats to find.
If FUSE still works the same way, then it sounded like an option for me, but for the same reasons as here: Request for classic confinement: parsec It ultimately doesn’t make sense for me, needs root and no unmounting, etc… In that case you guys did grant classic. That case was not identical of course, if I read correctly, then the source of the data they are exposing is the crucial difference, I think they were looking to mount data from inside the snap to make it available whereas I’m looking for the opposite, to mount a location from outside the snap inside it to make it writeable.
I may be making some arguments from ignorance here, I apologize if I am.