Re: [gentoo-dev] RFC: Userkit.eclass

[Michael Mol]

On Monday, November 28, 2016 02:39:48 PM William L. Thomson Jr. wrote:
> On Monday, November 28, 2016 10:42:54 AM EST Alec Warner wrote:
> > Generally speaking as a fellow who maintained thousands of systems (many
> > of
> > which ran various operating systems.)
> >
> > You cannot rely on all OS vendors to synchronize uid / gid. You cannot
> > even
> > rely on some single vendors to synchronize uid / gids between releases of
> > their own products.
>
> I believe the main reason such is the case is a lack of any such list or
> database for others to adhere to. Once again an area Gentoo could be
> leading. Had Gentoo done this years ago others might have adopted.
>
> IMHO it is something that should be  a part of LSB. If not POSIX in general.
> One cannot really change the past or current state of things. But can make
> the future better.

Highly detailed lists like that--used as a broad standard--are a bad idea. 
They represent a single synchronization point that everyone must adhere to. 

That means that every prospective adjustment to the list requires active 
maintenance. That means that for every new daemon someone writes, they have to 
go through an admissions process. For every contentious fork of a project, you 
risk conflict over who the designated contact for the assignment should be.

It adds a large bureaucratic load on everyone. Every itch some developer 
thinks about scratching has to be weighed against engaging with some process-
laden entity. Maybe they'll participate, but they likely won't.

Have you watched the IANA ports assignment registry over the years? Consider 
how many services and tools you've seen that *don't* respect it.

And what is the list managing? A limited namespace, currently only 32 bits, 
but with tools like, say, Samba and sssd reserving large chunks for stable UID 
and GID mapping. One could argue that a stable list could obviate the need for 
some of that mapping, but you've got decades-old existing networks that aren't 
going anywhere, and you'll still need to interface with systems run by people 
who will deliberately run counter to such lists as a security layer, just as 
you interface with systems that run SSH or HTTP on nonstandard ports.

You'll still run into all of these issues and more if you try generalize the 
list to region allocation:

Say you try to assign regions for system daemons vs users, and you're on a 
host that interacts with two other hosts without full mutual trust. You're 
serving up a shared filesystem, and all three involved hosts each have a system 
daemon user and a system normal user with an object on that shared filesystem.

Presented with a directory listing showing the UIDs and GIDs for each object, 
how do you distinguish between the system user from each host? The two hosts 
shouldn't have access to each others' files, even if they use the same UID 
locally, because the two hosts don't trust each other.

That considered, how, then, how do you identify between another host's system 
user and its normal user, inasmuch as you can't let them collide with IDs on 
your own system, but are trying to ensure that their IDs get mapped into the 
correct local range?

That considered, what do you do when the Big List Maintainers add another 
region? How do you cope with another host that uses a newer version of that 
list? An older version? And now that you've upgraded, and the new version of 
the list says you should have mapped something somewhere else, what do you do 
with it? Do you even have enough information to know that an ID you mapped 
last year should have been in that other category?

And while we're talking about allocating ranges, we can start talking about 
limited address space. 32 bits seems like a lot of individual identities, but 
when you're carving it up into multiple masses of identities, you'll find it 
gets very small, very quickly. That's why IPv6 went with 128 bits instead of a 
64 bit address space.

All of this is why we use identity management tools like LDAP in the first 
place. Heck, it's why we have passwd and group files for mapping names to ids 
and didn't simply hardcode system IDs decades ago.

-- 
:wq