Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

[Alec Warner]

On Sun, Nov 28, 2021 at 8:07 PM Michał Górny <mgorny@g.o> wrote:
>
> On Sun, 2021-11-28 at 16:31 -0600, William Hubbs wrote:
> > All,
> >
> > I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting
> > for all acct-user and acct-group packages in ::gentoo.
> >
> > Here are my thoughts about it.
> >
> > - As Gordon pointed out, it isn't necessary for us to care about UIDS/GIDS
> >   most of the time.
> >
> > - I realize that our settings are suggestions, but the values we can
> >   suggest are not infinite. We have run out once, and it is only a matter of
> >   time until we do again.
> >
> > - If an end user needs to care about the UID/GID, they can easily override
> >   the settings in make.conf.
> >
> > In short, I don't think we should be forcing maintainers to pick a
> > specific UID/GID for every package that needs a user/group. Most of the
> > time they can set ACCT_USER_ID and ACCT_GROUP_ID to -1.
> >
> > Thoughts? In particular, I want to hear from folks who disagree with me
> > about using -1 in the main tree for most packages.
> >
>
> Let me put this bluntly.  Yes, most users don't care.  However:
>
> 1) if we don't assign static UIDs/GIDs, the few users who care are gonna
> be in hell having to assign them all manually.  Every single one of
> them, on every one of their systems.

I think the challenge here for me is twofold:

 - I need some source of truth in gid / uids. Most places already have
one (some kind of identity provider.)
 - I need some way to distribute the truth to my machines. In industry
we use nsscache, or sssd, or ldap, or nis+, or yp, or samba, or you
hardcode uid / gids in our configuration management pipeline (ansible,
chef, puppet, our container build scripts!) For instance Gentoo Infra
does a mix of LDAP (our source of truth for uid / gid) and nsscache
(to distribute the uids and gids to machines) as well as hardcoded uid
/ gids (often for services.)

Many people have both of these already. They have some identity
provider (LDAP, AD, FreeIPA, a yaml file!) and they have some way of
getting those identities to their boxes. So when you say things like
"well these people have to do this manually" I struggle to really
understand who these people are; and how things like a yaml file +
ansible script is not sufficient to address this problem for them.
Syncing uid / gids across machines is a solved problem. Some of the
solutions (freeIPA, LDAP) are gross for home use; but ansible is
pretty lightweight, for example.

>
> 2) if we do assign static UIDs/GIDs... what's the problem, again?
> Little extra work for a few devs?

I think we are back to like "why do we care about the uid / gid ranges
at all?" and the answer is because many people have an existing
identity scheme and the gentoo scheme interacts poorly with it.

- If Gentoo adds an acct-user/foo user, and that user already exists
on my system with the wrong UID: the eclass dies[0].
- If Gentoo adds an acct-user/foo user, with uid=12345, and that uid
is assigned to a user on my system already, the eclass dies.
- Some environments are very old, and so real users have unexpected
uids; this includes Gentoo itself.
   - Gentoo (the community) used to allocate UIDs to devs in the
500-1000 range and we have 17 active developers with UIDs in that
range. So for example if we allocate one of these UIDs to an acct-*
package; that package will not be installable on woodpecker without
modification because those UIDs are already taken.
   - Other organizations are similarly encumbered with state; and
these systems do not interact well with the current defaults.

I'm looking for a documented way to say "hey I want dynamic allocation
on this machine; even in ::gentoo, because I have an existing scheme I
want to use." I want to do it in one place, and not have to set dozens
of package.env files, or copy ebuilds, or hack the eclasses. One idea
I had was some bashrc hacks to always set ACCT_USER_ID=-1 (and
ACCT_GROUP_ID=-1); as this might achieve that goal...but it would be
nicer to probably just set some accepted make.conf var.

-A

[0] Also there are just hilarious stories of weird names in industry.
We had one person who joined who got assigned the username 'lib' and
so their homedirectory was '/home/lib/'. All kinds of random crap
broke with that name and we had to bughunting in some apps...and we
reserved a bunch of similar names so they would not be taken. Or
another case: our uid allocator had a bug and we assigned a real
person the nobody uid; turns out NFS does not work well when you do
that.



>
> --
> Best regards,
> Michał Górny
>
>