| 1 |
On 12/9/19 3:10 PM, Thomas Deutschmann wrote: |
| 2 |
> On 2019-12-09 19:48, Ulrich Mueller wrote: |
| 3 |
>>>>>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote: |
| 4 |
>> |
| 5 |
>>> Like said, if an ID is already taken for any reason on user's system, |
| 6 |
>>> that's not a problem. acct-* can handle that... there's nothing like a |
| 7 |
>>> collision. |
| 8 |
>> |
| 9 |
>> You can call it "collision" or something else, the fact is that in this |
| 10 |
>> scenario, the acct-* package won't get its preferred ID. Which is the |
| 11 |
>> whole point of the migration to static IDs. You can consider this |
| 12 |
>> unimportant, but why do we have GLEP 81 then, in the first place? |
| 13 |
> |
| 14 |
> Heh, I am sorry but I think your expectation is wrong here: |
| 15 |
> |
| 16 |
> From my understanding, the authors of GLEP 81 should correct me if I am |
| 17 |
> wrong, the main idea was to get stable IDs across multiple Gentoo systems. |
| 18 |
> |
| 19 |
|
| 20 |
Since I have been summoned... the stable UID/GIDs were not the main |
| 21 |
motivation for GLEP81. The big problem it solves is that we had multiple |
| 22 |
packages creating "shared" users in the same namespace, either |
| 23 |
|
| 24 |
(a) without knowing that they were shared, or |
| 25 |
(b) trying to keep every piece of copy/pasted user data in sync. |
| 26 |
|
| 27 |
This lead to some dumb security vulnerabilities, like using the "milter" |
| 28 |
user for anything that looks at an email. On a mail server you wind up |
| 29 |
with five unrelated daemons being able to write to each others' private |
| 30 |
files. For another example, the "ntp" user was fought over by at least |
| 31 |
two packages that insisted on certain (mutually exclusive) settings for |
| 32 |
the same user. Whether or not your daemon worked depended on which |
| 33 |
ebuild was re-emerged last. |
| 34 |
|
| 35 |
GLEP81 solves that, and factors out the user data so that multiple |
| 36 |
packages can share a user without having to copy/paste its settings and |
| 37 |
keep them synchronized. It also addresses the fact that some users are |
| 38 |
needed at both build/runtime, while others are needed only at runtime. |
| 39 |
In the past, enewuser calls were placed randomly in one of pkg_setup() |
| 40 |
or pkg_preinst(), and you'd wind up with users on your system for |
| 41 |
packages that failed to build. Now you just depend on the acct-user |
| 42 |
package in DEPEND or RDEPEND like anything else. |
| 43 |
|
| 44 |
The very first RFC didn't even include fixed UIDs, but a lot of people |
| 45 |
requested them. I can see how it's useful. Every few years, I have to |
| 46 |
replace a mail server and rsync over the contents of the mail store. On |
| 47 |
the new server, I have to be very careful that the UIDs match up, which |
| 48 |
might not be the case depending on the order certain packages were |
| 49 |
emerged in. It's not too hard to do, but you have to know to do it, and |
| 50 |
it wastes some time. It'll be great not having to worry about that next |
| 51 |
time. If developers can spend a few minutes picking out a fixed UID to |
| 52 |
save users an hour here and there, I think it's worth it, because there |
| 53 |
are a lot more users than developers. |
Archives