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