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

[Alan McKinnon]

On 29/01/2017 19:05, Michael Orlitzky wrote:
> On 01/29/2017 03:26 AM, Alan McKinnon wrote:
>>>
>>> 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.
>
> That's what I've got it doing now...
>
>
>> Preferably use a pre-assigned UID/GID so there is some consistency
>> with most other Gentoo things out there.
>
> This is the only point we have left to consider. To recap, there are
> three approaches to try:


[snip]

>   3 Mostly fixed UIDs, but with a fallback to random ones if you don't
>     get the UID you want. Here, everyone specifies their "preferred"
>     UID, and we try that first. If it doesn't work, you get the random
>     assignment.
>
>     Pros (w.r.t option 2):
>
>       * On a new installation, all of the UIDs that are assigned will
>         likely be fixed, so you get some of the benefit of the first
>         option without having to create an overlay.

This is my preferred choice

>
>     Cons (w.r.t. option 2):
>
>       * The upgrade path is a little hairier. On an existing system,
>         we'll be introducing a bunch of new user packages that want
>         a particular UID but don't get it. On existing systems, the
>         UID assignment will still essentially be random. That's
>         problematic for packages that truly need the UID they've
>         requested.

I say drop the upgrade path entirely. Why do you as a dev care?
You've made a compelling case that making any changes at all is hairy,
so don't even try and automate it.

As a mere user I personally would never expect Gentoo devs to deal with
this, and if there's a knob in make.conf to enable/disable such a user
upgrade path, I'd probably disable it.

I've had to do this exercise more times than I care to admit, usually to
get multiple machines across a network in sync or to deal with nfsv3,
and it's not something I'd ever dare throw a script or ebuild at.

If you achieved the simpler status of new installs of packages get the
preferred UID if available, then I'm 100% happy and over the moon.
Everything else is my problem, not yours (although I appreciate the
effort to even make the attempt)

> Option #1 is pretty much dead in the water without an upgrade path.
> We're considering #2 and #3 at the moment, but they're really not
> that different.
>
>
>> 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)
>>
>
> There's no safe way to do that. If you call chown (as root) on
> everything in a user-owned directory, that user can just create a
> symlink to e.g. /root/.bashrc and you'll give it root. It's really a
> miserable time trying to switch ownership of anything safely once it's
> been created.

Sure it can be done, just don't chown -R <user> ~user. DO it the VERY
long way round, file by file. Say you changed user "awesome" uid 300 to 400:

find / -uid 300 -exec chown awesome {} \+

It works every time, but involves " find / " - ouch - and you can't do
it if the user is logged in or has running processes. This is all for
system accounts, so I reckon you have a huge show stopper right there,
requiring admin intervention

-- 
Alan McKinnon
alan.mckinnon@×××××.com