| 1 |
On 01/27/2017 11:21 PM, Rich Freeman wrote: |
| 2 |
> |
| 3 |
> It isn't like inconsistent UIDs are the end of the world. However, |
| 4 |
> IMO it still makes sense to at least try to standardize such things. |
| 5 |
> Really, if you have a package always installing the same user simply |
| 6 |
> sticking a default UID without any effort to avoid collisions is |
| 7 |
> better than nothing, but having a wiki page where people can register |
| 8 |
> UIDs isn't that big a deal. |
| 9 |
> |
| 10 |
|
| 11 |
I threw together an ugly implementation so I could play with both |
| 12 |
approaches -- random or fixed UIDs by default. The code to get user and |
| 13 |
group management working is of course nice and simple in either case. |
| 14 |
Where they both turn to shit is the upgrade path. |
| 15 |
|
| 16 |
Here's a problem I have no solution for. Suppose we tell everyone to |
| 17 |
pick a fixed UID for their user packages. I have a randomly assigned |
| 18 |
"tcpdump" user as UID 102 on my machine today. If we roll this out next |
| 19 |
week and the tcpdump maintainer chooses UID=321 as his fixed UID, what |
| 20 |
happens when I go to install sys-user/tcpdump? Every option is bad: |
| 21 |
|
| 22 |
* Keep the existing user. Now its UID is wrong. You might say "so |
| 23 |
what," but the majority of users on the majority of systems are |
| 24 |
going to have this problem, so you have to wonder what we've |
| 25 |
gained by deciding on fixed UIDs and then ultimately assigning |
| 26 |
them randomly anyway. |
| 27 |
|
| 28 |
There's the related problem of what to do if the tuxracer maintainer |
| 29 |
decides he wants to use UID=102 and I still have tcpdump using it. |
| 30 |
|
| 31 |
* Overwrite the existing user with the new one. Your packages all |
| 32 |
break. |
| 33 |
|
| 34 |
* Have the ebuild die(), and tell the user to fix the UID and file |
| 35 |
ownership himself before emerge can continue. Good luck with that. |
| 36 |
|
| 37 |
In the mostly-random-UIDs approach, I have an answer, even if it's not |
| 38 |
pretty: I can use the pre-existing UID instead of the next available |
| 39 |
one. This still fails if the ebuild author requests a specific |
| 40 |
(conflicting) UID, but that should be extremely rare in the random-UIDs |
| 41 |
model. |
| 42 |
|
| 43 |
Can anyone think of an upgrade path for fixed UIDs? That issue aside, I |
| 44 |
may have convinced myself that fixed UIDs are better. |
Archives