snapd

Bug #1620771
Comment #53

Comment 53 for bug 1620771

Revision history for this message

C. Alex. North-Keys (erlkonig-talisman) wrote on 2021-07-25:

#53

After reading through this and the related page with more info about @{HOMEDIRS} I have to point out what should by this time just be a "metoo":

You absolutely cannot dictate where home directories "should" be or whether symlinks, weird mounts, fuser, or anything else bizarre is involved and still have snaps be viable in complex sites where homes literally can't be all stuffed /home and still have the site work properly.

Nor can you expect there to be a single directory containing all homes. Ever. "/root" e.g. and that's only the start.

I *think* it's safe to expect that every user, that has a $HOME directory, has a unique home directory. There might be some crazy site that has multiple users sharing a home using group access rights, but I'd expect they're already having problems so they don't really expect everything to be perfect.

The suggestion I read where you might locate the home directory and make it appear as /home/$USER inside the snap is... interesting, but may lead software running in the snap to write this possibly imaginary homepath (if the user's home in /homes/cs/staff/jws for example) into files that software running outside of the snap won't be able to use.

Additionally, don't be tempted to figure out whether the home "really" is instead of using the literal home directory from $HOME, since there are plenty of scenarios - *especially* certain variants of automount - where trying to be smart will miss a trigger that mounts the filesystem the home is in (or that keeps it mounted). In other words, you can't even trust "pwd" to give you a reusable, supposedly-more-real $HOME.

(Detail: Automounted dirs used to appear under /tmp_mnt/, but if you then used that output from "pwd" instead of the actual $HOME, usage wouldn't be noticed by automount, the user's home would get dismounted, and references via /tmp_mnt/ wouldn't trigger remounting it!)

So you need to make the literal, exact value of $HOME work *inside* of a snap in order for snaps to work, and keep Ubuntu viable, in many organizations.

Lastly, just using "dpkg-reconfigure apparmor" showed the right input, but it didn't fix hello-world, but I haven't actually rebooted yet. Sysadmins hate rebooting, so it's essential to have instructions that clearly show how to have the changes take affect without a reboot.

After reading through this and the related page with more info about @{HOMEDIRS} I have to point out what should by this time just be a "metoo":

Nor can you expect there to be a single directory containing all homes.  Ever. "/root" e.g. and that's only the start.

I *think* it's safe to expect that every user, that has a $HOME directory, has a unique home directory.  There might be some crazy site that has multiple users sharing a home using group access rights, but I'd expect they're already having problems so they don't really expect everything to be perfect.

Additionally, don't be tempted to figure out whether the home "really" is instead of using the literal home directory from $HOME, since there are plenty of scenarios - *especially* certain variants of automount - where trying to be smart will miss a trigger that mounts the filesystem the home is in (or that keeps it mounted).  In other words, you can't even trust "pwd" to give you a reusable, supposedly-more-real $HOME.

So you need to make the literal, exact value of $HOME work *inside* of a snap in order for snaps to work, and keep Ubuntu viable, in many organizations.

Lastly, just using "dpkg-reconfigure apparmor" showed the right input, but it didn't fix hello-world, but I haven't actually rebooted yet.  Sysadmins hate rebooting, so it's essential to have instructions that clearly show how to have the changes take affect without a reboot.