On 12/9/19 3:10 PM, Thomas Deutschmann wrote:
> On 2019-12-09 19:48, Ulrich Mueller wrote:
>>>>>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
>>
>>> Like said, if an ID is already taken for any reason on user's system,
>>> that's not a problem. acct-* can handle that... there's nothing like a
>>> collision.
>>
>> You can call it "collision" or something else, the fact is that in this
>> scenario, the acct-* package won't get its preferred ID. Which is the
>> whole point of the migration to static IDs. You can consider this
>> unimportant, but why do we have GLEP 81 then, in the first place?
> 
> Heh, I am sorry but I think your expectation is wrong here:
> 
> From my understanding, the authors of GLEP 81 should correct me if I am
> wrong, the main idea was to get stable IDs across multiple Gentoo systems.
> 

Since I have been summoned... the stable UID/GIDs were not the main
motivation for GLEP81. The big problem it solves is that we had multiple
packages creating "shared" users in the same namespace, either

  (a) without knowing that they were shared, or
  (b) trying to keep every piece of copy/pasted user data in sync.

This lead to some dumb security vulnerabilities, like using the "milter"
user for anything that looks at an email. On a mail server you wind up
with five unrelated daemons being able to write to each others' private
files. For another example, the "ntp" user was fought over by at least
two packages that insisted on certain (mutually exclusive) settings for
the same user. Whether or not your daemon worked depended on which
ebuild was re-emerged last.

GLEP81 solves that, and factors out the user data so that multiple
packages can share a user without having to copy/paste its settings and
keep them synchronized. It also addresses the fact that some users are
needed at both build/runtime, while others are needed only at runtime.
In the past, enewuser calls were placed randomly in one of pkg_setup()
or pkg_preinst(), and you'd wind up with users on your system for
packages that failed to build. Now you just depend on the acct-user
package in DEPEND or RDEPEND like anything else.

The very first RFC didn't even include fixed UIDs, but a lot of people
requested them. I can see how it's useful. Every few years, I have to
replace a mail server and rsync over the contents of the mail store. On
the new server, I have to be very careful that the UIDs match up, which
might not be the case depending on the order certain packages were
emerged in. It's not too hard to do, but you have to know to do it, and
it wastes some time. It'll be great not having to worry about that next
time. If developers can spend a few minutes picking out a fixed UID to
save users an hour here and there, I think it's worth it, because there
are a lot more users than developers.

Reply via email to