[NOTE: Frustration expressed. If Snap devs have solved these problems, hooray, you should still have to read how you made thousands or more people feel in the meantime for not doing the obvious]
This has been an underlying problem in the Snap mindset for years now, going against Unix and Linux standard practice the entire time. Snap staff does not appear to understand what happens in large-scale environments, and instead is restricting it to the small. To Wit:
- Home directories can be ANYWHERE, not just in the non-standard /home
- There are potentionally hundreds of mount points that can contain home directories
- The mount points cannot be predicted to the level just above $HOME in automounts
- It is essential to be able to trust multiple levels down from a given base directory
Example: Many sites have automount maps that allow home directories resident on users’ workstation to be visible site wide through automounting. The (LDAP) password entries have home directories similar to /nfs/somehostnick/some/path/name/username - and this is just a simple case, I’m not even going to go into the Andrew File System and its worldwide pathnames, where again, home directories can look entirely arbitrary other than that base directory referring to some service. Also, these sites have been around forever (in some cases) and can’t change themselves to fit some developer’s pet mission to “secure” home paths by scaling them down to his/her personal perception of what constitutes reasonable.
So, now people are going to jump in and so, “Oh, just make /home and automap for everyone’s home directories instead of them been scattered everywhere!” - which makes sense, except that it rarely works well above a few thousand users, because there’s a lot of lag around fetching inode information (ACROSS THE PLANET FOR AFS!) or from hosts that are down, or when some reasonable person has decided to run a script to iterate through all known homes to look at dotfiles or something. It takes multiple minutes to make a long listing of /home/ at many sites trying to make the /home “standard” (which it isn’t) work.
So for anything thinking the Snap home directory model as it stands (dare I hope for “stood”?), will EVER work in the real world, you are wrong, developers included.
Snap home directory trust needs to have ways to do the following:
- Trust anything claimed to be a home directory through password entry (including LDAP)
- Trust anything under an abitrary prefix (like the /nfs and /afs random examples)
- Trust anything at all, if the admins want to set the above prefix to “/”
- If a trusted path uses symlinks, or odd mounts, Snap needs to trust the directory reached
If snap fails to support these cases, then snap has failed, period. And I say this as I go to either dpkg versions of Thunderbird and Firefox, or just compile them myself again, because this braindamage just doesn’t seem to go away.
