On 2019-12-09 19:48, Ulrich Mueller wrote: >>>>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote: > >> Like said, if an ID is already taken for any reason on user's system, >> that's not a problem. acct-* can handle that... there's nothing like a >> collision. > > You can call it "collision" or something else, the fact is that in this > scenario, the acct-* package won't get its preferred ID. Which is the > whole point of the migration to static IDs. You can consider this > unimportant, but why do we have GLEP 81 then, in the first place?
Heh, I am sorry but I think your expectation is wrong here: From my understanding, the authors of GLEP 81 should correct me if I am wrong, the main idea was to get stable IDs across multiple Gentoo systems. I personally doubt that it's worth because it's very rare that you will only have to deal with Gentoo boxes so if you really *need* same user/ID for some reason you will have other mechanism already in place (configuration management, LDAP..). Of course, if you only have to deal with Gentoo, it might save you some work. Anyway, now we have GLEP 81. However, everyone should be clear about the fact that GLEP 81 migration *cannot* and will *not* work for *existing* systems which have the packages before GLEP 81 became a thing already installed. That's because acct-* will *not* and *cannot* alter existing user. In practice, nobody maintaining a lot of systems will actually reinstall all their Gentoo boxes just to get these new IDs. Like said, if they care about ids, they already have other mechanism in place. So when we talk about GLEP 81 we *can* only talk about greenfield aka new installation. No need to care about "collision" on systems before GLEP 81 (you cannot avoid them and it's just not worth)... tl;dr GLEP 81 describes a perfect world scenario. It's not giving us anything for real and anyone carrying about numbers must probably have mechanism in place which will handle that and work not just on Gentoo. That said, blocking 501-999 for now could be a valid goal to avoid fragmentation and see how things will work. When we decide to do that, we should document the exact reason. Saying "because of user.eclass or to avoid collision" is not a valid reason. > Also, what about users calling "useradd -r" manually, for whatever > purpose? They'll get IDs counting from 999 downwards as well, even after > the transition will be complete. shadow does that to avoid reuse of ids used by former, now deleted users, see https://github.com/shadow-maint/shadow/blob/4.8/libmisc/find_new_uid.c#L224 It's just an attempt to be smart. It's assuming that system(packages) will go upwards so when the user invoking useradd will go downwards you will probably not reuse id from user which got deleted but is still owning files/ACLs. Note: That's why Debian's useradd wrapper, adduser, is doing the opposite. It's starting with MIN and is going upwards... so we should do the same when picking IDs to help shadow being smart and avoid reuse as long as possible. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
signature.asc
Description: OpenPGP digital signature
