On Sun, Nov 28, 2021 at 8:07 PM Michał Górny <mgo...@gentoo.org> 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 > >
