1 |
On 29/01/2017 03:56, Michael Orlitzky wrote: |
2 |
> On 01/27/2017 11:21 PM, Rich Freeman wrote: |
3 |
>> |
4 |
>> It isn't like inconsistent UIDs are the end of the world. However, |
5 |
>> IMO it still makes sense to at least try to standardize such things. |
6 |
>> Really, if you have a package always installing the same user simply |
7 |
>> sticking a default UID without any effort to avoid collisions is |
8 |
>> better than nothing, but having a wiki page where people can register |
9 |
>> UIDs isn't that big a deal. |
10 |
>> |
11 |
> |
12 |
> I threw together an ugly implementation so I could play with both |
13 |
> approaches -- random or fixed UIDs by default. The code to get user and |
14 |
> group management working is of course nice and simple in either case. |
15 |
> Where they both turn to shit is the upgrade path. |
16 |
> |
17 |
> Here's a problem I have no solution for. Suppose we tell everyone to |
18 |
> pick a fixed UID for their user packages. I have a randomly assigned |
19 |
> "tcpdump" user as UID 102 on my machine today. If we roll this out next |
20 |
> week and the tcpdump maintainer chooses UID=321 as his fixed UID, what |
21 |
> happens when I go to install sys-user/tcpdump? Every option is bad: |
22 |
> |
23 |
> * Keep the existing user. Now its UID is wrong. You might say "so |
24 |
> what," but the majority of users on the majority of systems are |
25 |
> going to have this problem, so you have to wonder what we've |
26 |
> gained by deciding on fixed UIDs and then ultimately assigning |
27 |
> them randomly anyway. |
28 |
> |
29 |
> There's the related problem of what to do if the tuxracer maintainer |
30 |
> decides he wants to use UID=102 and I still have tcpdump using it. |
31 |
> |
32 |
> * Overwrite the existing user with the new one. Your packages all |
33 |
> break. |
34 |
> |
35 |
> * Have the ebuild die(), and tell the user to fix the UID and file |
36 |
> ownership himself before emerge can continue. Good luck with that. |
37 |
> |
38 |
> In the mostly-random-UIDs approach, I have an answer, even if it's not |
39 |
> pretty: I can use the pre-existing UID instead of the next available |
40 |
> one. This still fails if the ebuild author requests a specific |
41 |
> (conflicting) UID, but that should be extremely rare in the random-UIDs |
42 |
> model. |
43 |
> |
44 |
> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I |
45 |
> may have convinced myself that fixed UIDs are better. |
46 |
|
47 |
The general process I would recommend is that if the ebuild finds the user |
48 |
already exists, leave it, it's UID and it's file ownerships alone, and keep |
49 |
them as they are. If the user does not exist then create it. Preferably |
50 |
use a pre-assigned UID/GID so there is some consistency with most other |
51 |
Gentoo things out there. |
52 |
|
53 |
If the user already exists, it's presumably because the sysadmin wants |
54 |
it that way or it was installed that way from an older ebuild. Either |
55 |
way the ebuild cannot mess around with that. It could output an elog |
56 |
saying the uid/gid doesn't match the new Gentoo norm, and provide the |
57 |
commands to run to bring things into line (usermod, groupmod, find / |
58 |
-user -exec chown, etc, etc) |
59 |
|
60 |
|
61 |
|
62 |
-- |
63 |
Alan McKinnon |
64 |
alan.mckinnon@×××××.com |