|
[NOTE: Frustration expressed. If Snap devs have solved these problems,
hooray, they should still have to read how they 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.
|