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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

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.

Thanks,

William


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Orlitzky]

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.

It's not for you. It's for end users. And you don't have to care about
them. Just pick any old number.


> - 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.

We did not run out. The council placed an arbitrary limit on them once,
and then had to raise their own arbitrary limit.

Nobody complaining about "running out" understands what the GLEP says.
If we ever hit 2^16 acct-group packages, feel free to reuse them, or
keep counting. Nothing bad will happen. The worst case scenario is
still better than if no hint was given at all.


> - If an end user needs to care about the UID/GID, they can easily override
>   the settings in make.conf.

The point of the feature is to encourage all new installs to have
consistent UIDs/GIDs by default, without user intervention. Your
suggestion does not solve the same problem, and requires more work to
not solve it.


> 
> Thoughts? In particular, I want to hear from folks who disagree with me
> about using -1 in the main tree for most packages.
> 

The only problem that anyone has put forth is one that does not exist.
UIDs and GIDs are still assigned dynamically in Gentoo. The number you
type in the ebuild is only a hint: it's the first number that will be
tried during the dynamic assignment. There is no limit on the number of
hints, and we will never run out because a conflict is never possible,
because the damned things are assigned dynamically.

Is there an actual problem?

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

[Sam James]

[-- Attachment #1.1: Type: text/plain, Size: 880 bytes --]



> On 28 Nov 2021, at 23:26, Michael Orlitzky <mjo@gentoo.org> wrote:
> [sinp]
> The only problem that anyone has put forth is one that does not exist.
> UIDs and GIDs are still assigned dynamically in Gentoo. The number you
> type in the ebuild is only a hint: it's the first number that will be
> tried during the dynamic assignment. There is no limit on the number of
> hints, and we will never run out because a conflict is never possible,
> because the damned things are assigned dynamically.
> 
> Is there an actual problem?
> 

Could you look at this thread?

https://archives.gentoo.org/gentoo-dev/message/5bad6853520e3ab182f6399a53198fec <https://archives.gentoo.org/gentoo-dev/message/5bad6853520e3ab182f6399a53198fec>

Whissi and others raised some points that I think you may have some views on
(and I'm interested in hearing them).

best,
sam

[-- Attachment #1.2: Type: text/html, Size: 1587 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[Michael Orlitzky]

On Sun, 2021-11-28 at 23:39 +0000, Sam James wrote:
> 
> Whissi and others raised some points that I think you may have some views on
> (and I'm interested in hearing them).
> 

I don't want to put words in his mouth, but I think Whissi takes issue
with using the package manager to manage users, period. Not
specifically with our use of a UID/GID hint.

I didn't respond to the first thread because I didn't want to pick a
fight when the correct conclusion (IMO) was already reached. In the
first thread I see only hypothetical problems raised (and a bunch of
people who didn't realize the numbers are only a hint). If any of those
problems are real and solved by allowing ACCT_USER_ID=-1 in ::gentoo,
you'll have to point them out.

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

[Sam James]

[-- Attachment #1.1: Type: text/plain, Size: 2754 bytes --]



> On 29 Nov 2021, at 00:06, Michael Orlitzky <mjo@gentoo.org> wrote:
> 
> On Sun, 2021-11-28 at 23:39 +0000, Sam James wrote:
>> 
>> Whissi and others raised some points that I think you may have some views on
>> (and I'm interested in hearing them).
>> 
> 
> I don't want to put words in his mouth, but I think Whissi takes issue
> with using the package manager to manage users, period. Not
> specifically with our use of a UID/GID hint.
> 
> I didn't respond to the first thread because I didn't want to pick a
> fight when the correct conclusion (IMO) was already reached. In the
> first thread I see only hypothetical problems raised (and a bunch of
> people who didn't realize the numbers are only a hint). If any of those
> problems are real and solved by allowing ACCT_USER_ID=-1 in ::gentoo,
> you'll have to point them out.
> 

Yeah, that seems like a fair interpretation (and matches my understanding).

I don't really see the problem with people who want manual administration
just setting the relevant variables in make.conf.

What I wish we had done (and there's still time to do, albeit belated --
it's still useful for the remaining big bits like Apache and nginx) is
write a news item explaining the implications and linked to a page
like https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration <https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration>
(which ConiKost created after we discussed how to inform users better)
that explains how to work around/express their preferences/give their own hints.

Sorry, I should've been explicit. The main thing I'd like to understand better
from your POV is:

this isn't new, but you're quite clear you feel that the UID/GID range limitations
are completely arbitrary and without merit(?).

Whissi essentially says the opposite: https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450 <https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450>.

I'd like to understand if this is just a result of beliefs about what the PM should/shouldn't do
or if there's genuine problems with continuing to extend the range?

I think I'd like to see sources on various UID ranges being hardcoded in places as
I suspect any such software may have dubious quality anyway, but that's on him,
not you.

It still seems like in terms of interoperability, there's little impact:
folks can force whatever UIDs/GIDs they want. It's not like the situation was
any better with dynamic allocation unless you installed in exactly the right order
(so some precise setup wasrequired in the past anyway, the difference is now you
explicitly state what you want if you need it).

Best,
sam

[-- Attachment #1.2: Type: text/html, Size: 3876 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[Michael Orlitzky]

On Mon, 2021-11-29 at 05:05 +0000, Sam James wrote:
> 
> What I wish we had done (and there's still time to do, albeit belated --
> it's still useful for the remaining big bits like Apache and nginx) is
> write a news item explaining the implications and linked to a page
> like https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration <https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration>
> (which ConiKost created after we discussed how to inform users better)
> that explains how to work around/express their preferences/give their own hints.
> 

I agree, and there's still room to improve the user interface as well.
For example, I run postfix on all of my machines. A few of them also
need to run OpenDKIM, and need the postfix user to be a member of a
group that is shared with OpenDKIM, to access a socket.

To best integrate with the PM, the solution to this problem is to
override acct-user/postfix in an overlay. Ok, no problem. But since the
additional group should be optional, it needs to be controlled by a USE
flag if you want to use the same ebuild across your entire
organization. The implementation details make this a bit ugly:

  RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )"

  pkg_setup() {
    if use dkimsocket; then
      ACCT_USER_GROUPS+=( dkimsocket )
    fi
  }

The extra noise is necessary because "dkimsocket" needs to be added to
two arrays, and that can't be done declaratively at the moment. It
would be a nice UI improvement if the best solution was less of a
headache.



> Sorry, I should've been explicit. The main thing I'd like to understand better
> from your POV is:
> 
> this isn't new, but you're quite clear you feel that the UID/GID range limitations
> are completely arbitrary and without merit(?).
> 
> Whissi essentially says the opposite: https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450 <https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450>.
> 
> I'd like to understand if this is just a result of beliefs about what the PM should/shouldn't do
> or if there's genuine problems with continuing to extend the range?

Using the rest of the system range (500-999) should pose no problems
for anyone, since that's exactly what the old user.eclass will do. I
also see no problem with 60001+. I'm skeptical that any daemons have
those ranges hard-coded; and even if they do, they're buggy and we
shouldn't handicap the distribution over it.

More fundamentally, the "user" and "system" limits themselves not
written in stone: they are written in login.defs, and are only hints
for a few standard tools. Software should not be guessing at them. I
think we should try to keep things as consistent as possible with other
distributions, operating systems, and standards -- but if it comes down
to it, the numbers in the acct-* ebuilds are only suggestions, and it
doesn't hurt anything in the long run to suggest a number that might
already be taken because login.defs allowed useradd to take it in the
past.

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

[Michał Górny]

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.

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

-- 
Best regards,
Michał Górny

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@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
>
>

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

[Ulrich Mueller]

>>>>> On Mon, 29 Nov 2021, Alec Warner wrote:

> - If Gentoo adds an acct-user/foo user, and that user already exists
> on my system with the wrong UID: the eclass dies[0].

I don't think that's correct. The eclass will just use the already
existing UID then (except for the very few acct-user packages that
define ACCT_USER_ENFORCE_ID).

> - 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.

Similar to above, the eclass will dynamically allocate another UID that
is free.

> - 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.

See above.

Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.

Ulrich

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

[James Cloos]

>>>>> "UM" == Ulrich Mueller <ulm@gentoo.org> writes:

UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.

why do you thing gentoo is everyone's first or only dist on their
network?

or even on any given box?

forcing existing boxen to change just because a new dist is added
is also unacceptable.

for me though, it would be enough if there is something i can add to
make.conf to ensure that the acct-user and acct-group builds avoid the
ranges i already use.

that may also work for others.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

>>>>> On Tue, 30 Nov 2021, James Cloos wrote:

>>>>> "UM" == Ulrich Mueller <ulm@gentoo.org> writes:
UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.

> why do you thing gentoo is everyone's first or only dist on their
> network?

> or even on any given box?

I was specifically asking about Gentoo infra there.

> forcing existing boxen to change just because a new dist is added
> is also unacceptable.

> for me though, it would be enough if there is something i can add to
> make.conf to ensure that the acct-user and acct-group builds avoid the
> ranges i already use.

> that may also work for others.

UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always
used for dynamic allocation of system accounts. GLEP 81 hasn't really
changed anything there, except that the ebuild will now suggest an ID to
try first.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

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

[James Cloos]

>>>>> "UM" == Ulrich Mueller <ulm@gentoo.org> writes:

UM> I was specifically asking about Gentoo infra there.

ah; i completely missed that bit.

sorry for the misunderstanding.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Tue, Nov 30, 2021 at 12:59:18PM +0100, Ulrich Mueller wrote:
> >>>>> On Tue, 30 Nov 2021, James Cloos wrote:
> 
> >>>>> "UM" == Ulrich Mueller <ulm@gentoo.org> writes:
> UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
> UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.
> 
> > why do you thing gentoo is everyone's first or only dist on their
> > network?
> 
> > or even on any given box?
> 
> I was specifically asking about Gentoo infra there.
> 
> > forcing existing boxen to change just because a new dist is added
> > is also unacceptable.
> 
> > for me though, it would be enough if there is something i can add to
> > make.conf to ensure that the acct-user and acct-group builds avoid the
> > ranges i already use.
> 
> > that may also work for others.
> 
> UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always
> used for dynamic allocation of system accounts. GLEP 81 hasn't really
> changed anything there, except that the ebuild will now suggest an ID to
> try first.

This is the part of this that I don't understand. If we aren't enforcing
an ID, why do we care which ID to try first? It seems to be an
unnecessary step since users can pick the IDs they want by putting
settings in make.conf.

William

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michael Orlitzky]

On Tue, 2021-11-30 at 19:32 -0600, William Hubbs wrote:
> 
> This is the part of this that I don't understand. If we aren't enforcing
> an ID, why do we care which ID to try first? It seems to be an
> unnecessary step since users can pick the IDs they want by putting
> settings in make.conf.
> 

This way, all new installs have consistent IDs by default. Users having
to manually specify every ID on every system to have them be consistent
is exactly what we are trying to avoid.

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

[Jaco Kroon]

Hi,

On 2021/12/01 03:32, William Hubbs wrote:
> This is the part of this that I don't understand. If we aren't enforcing
> an ID, why do we care which ID to try first? It seems to be an
> unnecessary step since users can pick the IDs they want by putting
> settings in make.conf.

Because when running clusters of hosts it's useful to have the UIDs for
"system" users match.  Yes, I know this won't match in a multi-distro
setup, but at least for those of us with clusters consisting only of
Gentoo hosts it will *usually* match.  Changing these are possible, but
a nuisance, so having it "just work" for the usual case is great IMHO.

If I'm not mistaken there is a setting to REQUIRE the ID, and that could
even be set from make.conf, or env/ so for those packages that we care
about that (eg, mailman running on top of glusterfs) we use that.

Kind Regards,
Jaco

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

[Alec Warner]

On Tue, Nov 30, 2021 at 10:16 PM Jaco Kroon <jaco@uls.co.za> wrote:
>
> Hi,
>
> On 2021/12/01 03:32, William Hubbs wrote:
> > This is the part of this that I don't understand. If we aren't enforcing
> > an ID, why do we care which ID to try first? It seems to be an
> > unnecessary step since users can pick the IDs they want by putting
> > settings in make.conf.
>
> Because when running clusters of hosts it's useful to have the UIDs for
> "system" users match.  Yes, I know this won't match in a multi-distro
> setup, but at least for those of us with clusters consisting only of
> Gentoo hosts it will *usually* match.  Changing these are possible, but
> a nuisance, so having it "just work" for the usual case is great IMHO.

So questions from my side are:
Does your cluster not have human users?
Do the userids for the human users also not have to match between
hosts in the cluster?

-A

>
> If I'm not mistaken there is a setting to REQUIRE the ID, and that could
> even be set from make.conf, or env/ so for those packages that we care
> about that (eg, mailman running on top of glusterfs) we use that.
>
> Kind Regards,
> Jaco
>
>

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

[Jaco Kroon]

Hi,

On 2021/12/01 08:45, Alec Warner wrote:

> On Tue, Nov 30, 2021 at 10:16 PM Jaco Kroon <jaco@uls.co.za> wrote:
>> Hi,
>>
>> On 2021/12/01 03:32, William Hubbs wrote:
>>> This is the part of this that I don't understand. If we aren't enforcing
>>> an ID, why do we care which ID to try first? It seems to be an
>>> unnecessary step since users can pick the IDs they want by putting
>>> settings in make.conf.
>> Because when running clusters of hosts it's useful to have the UIDs for
>> "system" users match.  Yes, I know this won't match in a multi-distro
>> setup, but at least for those of us with clusters consisting only of
>> Gentoo hosts it will *usually* match.  Changing these are possible, but
>> a nuisance, so having it "just work" for the usual case is great IMHO.
> So questions from my side are:
> Does your cluster not have human users?
In this case none.  So no need for centralized database otherwise.
> Do the userids for the human users also not have to match between
> hosts in the cluster?

In certain environments we do need that, which is where nss_ldap and
friends come in.  In those environments the system ids doesn't matter
though, because only /home is shared :).

Kind Regards,
Jaco

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

[Michael Orlitzky]

On Tue, 2021-11-30 at 22:45 -0800, Alec Warner wrote:
> 
> So questions from my side are:
> Does your cluster not have human users?
> Do the userids for the human users also not have to match between
> hosts in the cluster?
> 
> 

You can easily create ebuilds for the human users who access the
system, and sets like @admins or @developers, so that all important
user information is ultimately recorded by the package manager.

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

[A Schenck]

[-- Attachment #1.1: Type: text/plain, Size: 2013 bytes --]

On 11/30/21 17:32, William Hubbs wrote:
> On Tue, Nov 30, 2021 at 12:59:18PM +0100, Ulrich Mueller wrote:
>>>>>>> On Tue, 30 Nov 2021, James Cloos wrote:
>>>>>>> "UM" == Ulrich Mueller <ulm@gentoo.org> writes:
>> UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
>> UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.
>>
>>> why do you thing gentoo is everyone's first or only dist on their
>>> network?
>>> or even on any given box?
>> I was specifically asking about Gentoo infra there.
>>
>>> forcing existing boxen to change just because a new dist is added
>>> is also unacceptable.
>>> for me though, it would be enough if there is something i can add to
>>> make.conf to ensure that the acct-user and acct-group builds avoid the
>>> ranges i already use.
>>> that may also work for others.
>> UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always
>> used for dynamic allocation of system accounts. GLEP 81 hasn't really
>> changed anything there, except that the ebuild will now suggest an ID to
>> try first.
> This is the part of this that I don't understand. If we aren't enforcing
> an ID, why do we care which ID to try first? It seems to be an
> unnecessary step since users can pick the IDs they want by putting
> settings in make.conf.
At risk of sounding pithy, it could maybe be summed up as: 'because
"Gentoo is about choice" (but a sensible default doesn't hurt).' As you
say "users _can_ pick the IDs they want," but if they don't happen to
want to, we've tried to pick defaults (which are even shared by other
distributions where possible) so that there's a greater than zero chance
that things will "just work" when the time comes for them to
interoperate. As a user, despite having initially installed way before
this was a thing, it seems nice. The new SBC (rockpro64) we installed
last year or so has a much more consistent user setup now than the
laptop which is just random.
>
> William
-A

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Alec Warner]

On Mon, Nov 29, 2021 at 2:25 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Mon, 29 Nov 2021, Alec Warner wrote:
>
> > - If Gentoo adds an acct-user/foo user, and that user already exists
> > on my system with the wrong UID: the eclass dies[0].
>
> I don't think that's correct. The eclass will just use the already
> existing UID then (except for the very few acct-user packages that
> define ACCT_USER_ENFORCE_ID).
>
> > - 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.
>
> Similar to above, the eclass will dynamically allocate another UID that
> is free.

Oh good I misread it, you are right; my apologies.

>
> > - 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.
>
> See above.
>
> Also, why would one allocate UIDs in the 500..999 range (1000 is fine,
> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999.

A bunch of reasons.
 - In the case of gentoo.org specifically I am guessing bugs and / or
ignorance (as we discussed on IRC.) enewuser / useradd / the normal
utilities lack the permissions to add users (because they cannot write
to LDAP without credentials) and so currently we have a tool
(perl_ldap); from 2006 onward it looks for the highest uidNumber in
LDAP and adds 1 to it. I don't have the source code for earlier
versions, but code comments implied the uids were entered by people;
not machines. People are really bad at consistently allocating UIDs
and are bad at following standards :)
 - In my previous work, the uid automation would routinely have bugs
(we did not have good unit or functional testing) and often the uid
range requirements were either not implemented (oops) or were buggy
(also oops.) We often fixed weird bugs by hand (if we noticed that
e.g. an account had some weird problem and it was someone's first day;
redoing their account is cheap.) But if the bug was in the past; it
was often too expensive to fix anything; so our user accounts had many
exciting quirks of names, odd assignments, etc.

This is why I say that conceptually the 'identity provider' is
external to Gentoo (because we all have our weird site-specific
quirks.) As you note above though, most acct-* packages will not break
and will just assign some other uid / gid; so only the FORCE_ID
packages matter and there are only 3 of those...so I mostly concede on
that basis provided we avoid adding more FORCE'd packages.

-A

>
> Ulrich