Re: [gentoo-dev] Requirements for UID/GID management

[M. J. Everitt]

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!