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? |
12 |
|
13 |
Heh, I am sorry but I think your expectation is wrong here: |
14 |
|
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. |
17 |
|
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. |
23 |
|
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. |
28 |
|
29 |
That's because acct-* will *not* and *cannot* alter existing user. |
30 |
|
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. |
34 |
|
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)... |
38 |
|
39 |
|
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. |
44 |
|
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. |
49 |
|
50 |
|
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. |
54 |
|
55 |
shadow does that to avoid reuse of ids used by former, now deleted |
56 |
users, see |
57 |
https://github.com/shadow-maint/shadow/blob/4.8/libmisc/find_new_uid.c#L224 |
58 |
|
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. |
63 |
|
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. |
68 |
|
69 |
|
70 |
-- |
71 |
Regards, |
72 |
Thomas Deutschmann / Gentoo Linux Developer |
73 |
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 |