On 29/01/17 01:56, Michael Orlitzky wrote: > On 01/27/2017 11:21 PM, Rich Freeman wrote: >> It isn't like inconsistent UIDs are the end of the world. However, >> IMO it still makes sense to at least try to standardize such things. >> Really, if you have a package always installing the same user simply >> sticking a default UID without any effort to avoid collisions is >> better than nothing, but having a wiki page where people can register >> UIDs isn't that big a deal. >> > I threw together an ugly implementation so I could play with both > approaches -- random or fixed UIDs by default. The code to get user and > group management working is of course nice and simple in either case. > Where they both turn to shit is the upgrade path. > > Here's a problem I have no solution for. Suppose we tell everyone to > pick a fixed UID for their user packages. I have a randomly assigned > "tcpdump" user as UID 102 on my machine today. If we roll this out next > week and the tcpdump maintainer chooses UID=321 as his fixed UID, what > happens when I go to install sys-user/tcpdump? Every option is bad: > > * Keep the existing user. Now its UID is wrong. You might say "so > what," but the majority of users on the majority of systems are > going to have this problem, so you have to wonder what we've > gained by deciding on fixed UIDs and then ultimately assigning > them randomly anyway. > > There's the related problem of what to do if the tuxracer maintainer > decides he wants to use UID=102 and I still have tcpdump using it. > > * Overwrite the existing user with the new one. Your packages all > break. > > * Have the ebuild die(), and tell the user to fix the UID and file > ownership himself before emerge can continue. Good luck with that. > > In the mostly-random-UIDs approach, I have an answer, even if it's not > pretty: I can use the pre-existing UID instead of the next available > one. This still fails if the ebuild author requests a specific > (conflicting) UID, but that should be extremely rare in the random-UIDs > model. > > Can anyone think of an upgrade path for fixed UIDs? That issue aside, I > may have convinced myself that fixed UIDs are better. > > I suspect that this would be best handled in an eclass with a stack of functions controlled by USE-flags or an eselect module or something. Seriously outta my league on this one .. but throwing the idea out there for anyone to discuss potential viability or not!
signature.asc
Description: OpenPGP digital signature
