Gentoo Archives: gentoo-dev

From: Thomas Deutschmann <whissi@g.o>
To: gentoo development <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)
Date: Mon, 09 Dec 2019 20:10:29
In Reply to: Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing) by Ulrich Mueller
1 On 2019-12-09 19:48, Ulrich Mueller wrote:
2 >>>>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
3 >
4 >> Like said, if an ID is already taken for any reason on user's system,
5 >> that's not a problem. acct-* can handle that... there's nothing like a
6 >> collision.
7 >
8 > You can call it "collision" or something else, the fact is that in this
9 > scenario, the acct-* package won't get its preferred ID. Which is the
10 > whole point of the migration to static IDs. You can consider this
11 > unimportant, but why do we have GLEP 81 then, in the first place?
13 Heh, I am sorry but I think your expectation is wrong here:
15 From my understanding, the authors of GLEP 81 should correct me if I am
16 wrong, the main idea was to get stable IDs across multiple Gentoo systems.
18 I personally doubt that it's worth because it's very rare that you will
19 only have to deal with Gentoo boxes so if you really *need* same user/ID
20 for some reason you will have other mechanism already in place
21 (configuration management, LDAP..). Of course, if you only have to deal
22 with Gentoo, it might save you some work.
24 Anyway, now we have GLEP 81. However, everyone should be clear about the
25 fact that GLEP 81 migration *cannot* and will *not* work for *existing*
26 systems which have the packages before GLEP 81 became a thing already
27 installed.
29 That's because acct-* will *not* and *cannot* alter existing user.
31 In practice, nobody maintaining a lot of systems will actually reinstall
32 all their Gentoo boxes just to get these new IDs. Like said, if they
33 care about ids, they already have other mechanism in place.
35 So when we talk about GLEP 81 we *can* only talk about greenfield aka
36 new installation. No need to care about "collision" on systems before
37 GLEP 81 (you cannot avoid them and it's just not worth)...
40 tl;dr
41 GLEP 81 describes a perfect world scenario. It's not giving us anything
42 for real and anyone carrying about numbers must probably have mechanism
43 in place which will handle that and work not just on Gentoo.
45 That said, blocking 501-999 for now could be a valid goal to avoid
46 fragmentation and see how things will work. When we decide to do that,
47 we should document the exact reason. Saying "because of user.eclass or
48 to avoid collision" is not a valid reason.
51 > Also, what about users calling "useradd -r" manually, for whatever
52 > purpose? They'll get IDs counting from 999 downwards as well, even after
53 > the transition will be complete.
55 shadow does that to avoid reuse of ids used by former, now deleted
56 users, see
59 It's just an attempt to be smart. It's assuming that system(packages)
60 will go upwards so when the user invoking useradd will go downwards you
61 will probably not reuse id from user which got deleted but is still
62 owning files/ACLs.
64 Note: That's why Debian's useradd wrapper, adduser, is doing the
65 opposite. It's starting with MIN and is going upwards... so we should do
66 the same when picking IDs to help shadow being smart and avoid reuse as
67 long as possible.
70 --
71 Regards,
72 Thomas Deutschmann / Gentoo Linux Developer
73 C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


File name MIME type
signature.asc application/pgp-signature