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
signature.asc
Description: This is a digitally signed message part.
