On 29/01/2017 03: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.
The general process I would recommend is that if the ebuild finds the user already exists, leave it, it's UID and it's file ownerships alone, and keep them as they are. If the user does not exist then create it. Preferably use a pre-assigned UID/GID so there is some consistency with most other Gentoo things out there. If the user already exists, it's presumably because the sysadmin wants it that way or it was installed that way from an older ebuild. Either way the ebuild cannot mess around with that. It could output an elog saying the uid/gid doesn't match the new Gentoo norm, and provide the commands to run to bring things into line (usermod, groupmod, find / -user -exec chown, etc, etc) -- Alan McKinnon alan.mckin...@gmail.com
