I have a use case where I want to run a Snap as a user with an “alternate” home directory such as /lhome/egee. Out-of-the-box, Snapd does not permit this and throws this error: /lhome/egee/snap/slurm/x1: Permission denied
I’ve seen the issue regarding Snapd not working well with alternate home directories discussed but the alleged “workaround” is often lost in the details and winds up being very unclear. And most of the topics for the workaround are a year or two old.
Is anyone able to summarize the current workaround in this thread or link to a concise post about it?
As things stand at the moment, there are two separate things that can break with non-default home directory locations:
AppArmor rules making use of the @{HOME} macro do not expand to a pattern that matches the user’s home directory
the snap-confine utility does not mount the user’s home directory into the private mount namespace used to sandbox strictly confined snaps.
For (1), it is possible to update how @{HOME} expands by editing /etc/apparmor.d/tunables/home.d/site.local, or dropping a new file in that directory that adds the new parent for home directories. You’ll need to regenerate the profiles after this change.
For (2), the snap-confine utility is hard coded to do recursive bind mounts of /root and home into the private mount namespace. There’s no easy way to override this. So you’re fine if your non-default home directory location is some subdirectory of /home, but not otherwise.
I know @zyga-snapd had some ideas about how to handle non-default locations in a more generic way, but I don’t think anything has come of that yet:
For enterprise use, this is a must have. I can’t think of mounting a large, TB network area under a user’s home so he can use LibreOffice, for instance. Any ETA (if at all) ?
There is no good way to handle this, that we know of, so far. We could try to do something that would map an arbitrary directory from on the host to /var/home/$LOGNAME and try to inject some PAM modules to help dealing with that but it’s a can of worms and is not scheduled on the roadmap yet.
I don’t think either would affect classic snaps. Classic snaps are given a permissive AppArmor policy (essentially unconfined but with a security label), and run in the host system’s mount namespace. So there should be no problem accessing weird home directory locations.
This problem still breaks snapd on Fedora Silverblue due to their use of /var/home for user home directories.
I’m also interested in how this might interact with distros that adopt systemd-homed for user home dir configuration in the future. Fedora seems the most likely to go down that road early too.
The /home mount inside the private mount namespace should be in MS_SHARED mode, which means that mounts under both it and /home in the main mount namespace will propagate to the other.
So it’s not obvious that systemd-homed would be a problem. The same would be true for any other automounter that makes home directories visible somewhere under /home.
Something that is more tractable in the short term might be a ‘snap set’ option for the system to configure where /home is globally (eg, /home/foo/user, use ‘snap set’ to set it to ‘/home/foo’) and also support per-user (eg, /var/homes/user, use ‘snap set’ to set the per-user home to ‘/home/foo’). ‘snap set’ would then update snap-confine policy in /var/lib/snapd/apparmor/snap-confine to allow snap-confine to create the directories in the user’s home, drop a snippet in /etc/apparmor.d/tunables/home.d to make snaps’ policy work (we could also do something in the profile preamble and rules instead of adding something to the system like that) and then drop something somewhere so that snap-confine/snap-update-ns know to use the configured location for the user. It isn’t fully automatic and requires admin action, but it would be a big step forward.
Improving on that, ‘snap install’ could look to see what the home directory is for the invoking user and provide an instructive message if the user should run ‘snap set’.
Hmm that is interesting, perhaps we are encountering a different issue? I created this forum post because I’ve been working on this issue. We are encountering this alternate home bug with our classic Snap.
I suspect in this case it is snap-confine that is failing to be able create the directory (separately from snaps, the setuid snap-confine binary has its own profile). The idea I posted above for ‘snap set’ would address this, but in the meantime, the best work around for your users is to bind mount /lhome/ubuntu onto /home/<something> (this is documented elsewhere in the forum).
I was thinking of using a similar approach to define “system accessible directories”, that should be mounted in the namespace of every strict snap. These should be defined by sysadmin (or savvy user, whatever) so that non-home directories could be visible inside snaps without being (bind) mounted inside user home.
I’m not talking about alternate homes, but enterprise data - reports, documents, etc… These shouldn’t be mounted on user’s home, as they’re not user data. Strictly confined snaps, as LibreOffice (that is absolutely necessary on a company) can’t access anything outside /home or the others directory you mentioned (AFAIK). As a sysadmin, I wouldn’t mount (or bind mount) terabytes on company’s data under no ones home (not even mine). Of course, the user could do it by themselves, but that’s a different story (and sysadmins could take measures to try to avoid it, maybe, if necessary).
alternate homes was @egeeirl first post topic, indeed.
I can hear you wouldn’t mount (or bind mount) terabytes on company’s data under no ones home but I guess you could mount only the necessary part of these data, given they’re organized to that purpose.
As for mounting only the necessary part, not feasible on 70k+ employees company, multi sector projects. But, again, you’re right, not the right place to discuss this.
For graphical applications, the long term goal should be to use xdg-desktop-portal. This will give confined applications access to any file the user can read on the host file system. This is balanced by only providing access to files the user picks through an out of process file chooser the confined app can’t control. In essence, the one file the user picks is mapped to a location the app can read/write to, and the app then works with that path.
It doesn’t really help for the "home directory outside of /home" use case, but it can help with “shared company data available from a custom mount point”.
70k+ so yes now I understand your need at such a scale.