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.