[gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

May I remind everybody that by QA policy allocation of UIDs and GIDs
in the range 0..100 needs explicit approval by the QA lead:
https://projects.gentoo.org/qa/policy-guide/user-group.html#pg0901

I have fixed the used_free_uidgids.sh script such that it will no longer
recommend any IDs below 101.

In any case, we have run out of GIDs:

   Recommended GID only: none
   Recommended UID only: 272
   Recommended UID+GID pair: none
   Free UIDs: 15
   Free GIDs: 0
   Free UID+GID pairs: 0

The question is of course how we should move forward. Certainly, using
IDs below 100 cannot be the solution, as we would run out of these very
soon.

We could:

- Open some part of the range between 500 and 1000. For example,
  500..799, which would leave 200 IDs for dynamic allocation.

- Open part of the range 60001..65533. Not sure if all software will be
  happy with that.

- Admit that the concept of static allocation has failed, and return to
  dynamic allocation.

Ulrich

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Florian Schmaus]

On 11/11/2021 11.59, Ulrich Mueller wrote:
> We could:
> 
> - Open some part of the range between 500 and 1000. For example,
>    500..799, which would leave 200 IDs for dynamic allocation.

+1, since I am not aware of any significant downsides doing so.

Could you elaborate why the range 500-799 only leaves us with 200 IDs?

- Flow

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Joonas Niilola]

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

On 11.11.2021 13.34, Florian Schmaus wrote:
> On 11/11/2021 11.59, Ulrich Mueller wrote:
>> We could:
>>
>> - Open some part of the range between 500 and 1000. For example,
>>    500..799, which would leave 200 IDs for dynamic allocation.
> 
> +1, since I am not aware of any significant downsides doing so.
> 
> Could you elaborate why the range 500-799 only leaves us with 200 IDs?
> 
> - Flow
> 
> 

Read it like this: Only 800-999 gets freed with this suggestion, as
500...999 is currently reserved for dynamic allocation. And >1000 is
also reserved.

-- juippis


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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

>>>>> On Thu, 11 Nov 2021, Florian Schmaus wrote:

>> We could:
>> - Open some part of the range between 500 and 1000. For example,
>> 500..799, which would leave 200 IDs for dynamic allocation.

> +1, since I am not aware of any significant downsides doing so.

> Could you elaborate why the range 500-799 only leaves us with 200 IDs?

We still need some range for dynamic allocation. Currently that is
500..999, and would be reduced to 800..999. That seems to be on the low
side already.

In any case, 300 additional IDs may not be future proof at the rate
we're currently allocating them. So I wonder if we shouldn't move to
above 60000 immediately, or alternatively, give up the whole concept.

Ulrich

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Pacho Ramos]

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

El jue, 11-11-2021 a las 12:48 +0100, Ulrich Mueller escribió:
> > > > > > On Thu, 11 Nov 2021, Florian Schmaus wrote:
> 
> > > We could:
> > > - Open some part of the range between 500 and 1000. For example,
> > > 500..799, which would leave 200 IDs for dynamic allocation.
> 
> > +1, since I am not aware of any significant downsides doing so.
> 
> > Could you elaborate why the range 500-799 only leaves us with 200 IDs?
> 
> We still need some range for dynamic allocation. Currently that is
> 500..999, and would be reduced to 800..999. That seems to be on the low
> side already.
> 
> In any case, 300 additional IDs may not be future proof at the rate
> we're currently allocating them. So I wonder if we shouldn't move to
> above 60000 immediately, or alternatively, give up the whole concept.
> 
> Ulrich

Personally I would move to >60000 and keep the 300 additional IDs for the case
some software really really needs them 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Jaco Kroon]

Hi,

On 2021/11/11 14:10, Pacho Ramos wrote:
> In any case, 300 additional IDs may not be future proof at the rate
>> we're currently allocating them. So I wonder if we shouldn't move to
>> above 60000 immediately, or alternatively, give up the whole concept.
>>
>> Ulrich
> Personally I would move to >60000 and keep the 300 additional IDs for the case
> some software really really needs them 

# getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3
37945
37946
65534 <-- this happens to be nobody.

>60000 up to where?  65533?  I'll need to make a "hole" in our
allocations but that's perfectly do-able.  Others may run into similar
issues and be caught unawares (especially if UID/GID values are
allocated from some other system which may not be aware of UID/GID
values on specific servers).  Might be worth the trouble to head to
>=2^31, but that will again fail on systems that still use 16-bit
UID/GID values (I'm not aware that we still support kernels older than 2.4).

https://systemd.io/UIDS-GIDS/ basically says system users (which we're
discussing here) is <1000.  systemd also already violates this statement
itself just a few paragraphs down with special systemd UID and GID
ranges.  And already >60000 ranges listed here (most of 60000 to 65533
is reserved by systemd).

Kind Regards,
Jaco

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

>>>>> On Thu, 11 Nov 2021, Jaco Kroon wrote:

> # getent passwd | awk -F: '{ print $3 }' | sort -g | tail -n3
> 37945
> 37946
> 65534 <-- this happens to be nobody.

> 60000 up to where?  65533?

I'd say 60001..60999 for now, and increase by another 1000 when (and if)
it will become necessary.

> I'll need to make a "hole" in our
> allocations but that's perfectly do-able.  Others may run into similar
> issues and be caught unawares (especially if UID/GID values are
> allocated from some other system which may not be aware of UID/GID
> values on specific servers).  Might be worth the trouble to head to
> >=2^31, but that will again fail on systems that still use 16-bit
> UID/GID values (I'm not aware that we still support kernels older than 2.4).

More than 16 bits may be problematic with containers. IIUC some of them
use a split scheme where the upper 16 bits are reserved.

> https://systemd.io/UIDS-GIDS/ basically says system users (which we're
> discussing here) is <1000.  systemd also already violates this statement
> itself just a few paragraphs down with special systemd UID and GID
> ranges.  And already >60000 ranges listed here (most of 60000 to 65533
> is reserved by systemd).

That's not a standard in any case, and it's dynamic allocation. So as
long as we don't fill up the whole range, things should be fine.

Ulrich

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ionen Wolkens]

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

On Thu, Nov 11, 2021 at 12:48:46PM +0100, Ulrich Mueller wrote:
> In any case, 300 additional IDs may not be future proof at the rate
> we're currently allocating them. So I wonder if we shouldn't move to
> above 60000 immediately, or alternatively, give up the whole concept.

Agreed here, I'd /like/ to stay <1000 for system IDs but I do also
feel we're just delaying the issue by using more of the dynamic range.
May as well keep it intact and larger.

Do think it's either open a range above 60000 or I guess switch to
using dynamic allocation in main ::gentoo as well (when non-critical).
-- 
ionen

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Florian Schmaus]

On 11/11/2021 12.48, Ulrich Mueller wrote:
>>>>>> On Thu, 11 Nov 2021, Florian Schmaus wrote:
> 
>>> We could:
>>> - Open some part of the range between 500 and 1000. For example,
>>> 500..799, which would leave 200 IDs for dynamic allocation.
> 
>> +1, since I am not aware of any significant downsides doing so.
> 
>> Could you elaborate why the range 500-799 only leaves us with 200 IDs?
> 
> We still need some range for dynamic allocation. Currently that is
> 500..999, and would be reduced to 800..999. That seems to be on the low
> side already.

Thanks. I simply missed the "for dynamic allocation" part in your 
initial mail. :/


> In any case, 300 additional IDs may not be future proof at the rate
> we're currently allocating them.

I am not so sure about that. Looking at the git log of uid-gid.txt there 
have been 3 allocations in the last 3 months. And around 4 months ago, 
conikost allocated a lot of IDs, which probably lead to the ID space 
exhaustion we are seeing. But I believe it could be possible that the ID 
allocation rate now stays low because we probably allocated IDs for most 
current use-cases now. So maybe the simplest and safest bet is to open 
the range from 500-799 for static IDs.

But I don't have a strong opinion on that.

- Flow

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Rich Freeman]

On Thu, Nov 11, 2021 at 6:34 AM Florian Schmaus <flow@gentoo.org> wrote:
>
> On 11/11/2021 11.59, Ulrich Mueller wrote:
> > We could:
> >
> > - Open some part of the range between 500 and 1000. For example,
> >    500..799, which would leave 200 IDs for dynamic allocation.
>
> +1, since I am not aware of any significant downsides doing so.
>

I will confess that 90% of the time that when I run into headaches due
to mismatching GID/UIDs it involves two different distros anyway.  I
definitely see the value in standardization, and there is some value
in doing it at the distro level, but really most of the value would
come from doing it cross-distro.

Ultimately I think a big part of the problem is that the whole UID/GID
model in Unix is a bit broken.  Of course that isn't going to change
anytime soon.

Probably still worth band-aid fixes for the time being.

-- 
Rich

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Mike Gilbert]

On Thu, Nov 11, 2021 at 5:59 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> May I remind everybody that by QA policy allocation of UIDs and GIDs
> in the range 0..100 needs explicit approval by the QA lead:
> https://projects.gentoo.org/qa/policy-guide/user-group.html#pg0901
>
> I have fixed the used_free_uidgids.sh script such that it will no longer
> recommend any IDs below 101.
>
> In any case, we have run out of GIDs:
>
>    Recommended GID only: none
>    Recommended UID only: 272
>    Recommended UID+GID pair: none
>    Free UIDs: 15
>    Free GIDs: 0
>    Free UID+GID pairs: 0
>
> The question is of course how we should move forward. Certainly, using
> IDs below 100 cannot be the solution, as we would run out of these very
> soon.
>
> We could:
>
> - Open some part of the range between 500 and 1000. For example,
>   500..799, which would leave 200 IDs for dynamic allocation.

This sounds like the simplest solution to me.

> - Open part of the range 60001..65533. Not sure if all software will be
>   happy with that.

systemd has some code that special-cases ids in the "system" range.
I'm not exactly sure what impact creating system users outside above
SYS_UID_MAX (login.defs) will have.

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

>>>>> On Thu, 11 Nov 2021, Mike Gilbert wrote:

>> - Open part of the range 60001..65533. Not sure if all software will be
>> happy with that.

> systemd has some code that special-cases ids in the "system" range.
> I'm not exactly sure what impact creating system users outside above
> SYS_UID_MAX (login.defs) will have.

We also have some IDs below SYS_UID_MIN (= 101) which technically is
outside the system account range of login.defs. Do these cause any
problems with systemd?

Ulrich

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Mike Gilbert]

On Thu, Nov 11, 2021 at 2:08 PM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Thu, 11 Nov 2021, Mike Gilbert wrote:
>
> >> - Open part of the range 60001..65533. Not sure if all software will be
> >> happy with that.
>
> > systemd has some code that special-cases ids in the "system" range.
> > I'm not exactly sure what impact creating system users outside above
> > SYS_UID_MAX (login.defs) will have.
>
> We also have some IDs below SYS_UID_MIN (= 101) which technically is
> outside the system account range of login.defs. Do these cause any
> problems with systemd?

That seems less likely to cause a problem. systemd considers any id <=
SYS_UID_MAX to be a system id.

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[James Cloos]

gentoo definitely should not permit fixed use for installed packages in
the 500-600 range.

500+ was for many, many years the start for users, and forcing anyone to
change decades-long use of particular uids or gods is not acceptable.

really all of 101-499,701-999,60000-{nobody--} should be dynamic.

and 500-700 never touched by the distribution.

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

>>>>> On Thu, 11 Nov 2021, James Cloos wrote:

> gentoo definitely should not permit fixed use for installed packages
> in the 500-600 range.

> 500+ was for many, many years the start for users, and forcing anyone
> to change decades-long use of particular uids or gods is not
> acceptable.

> really all of 101-499,701-999,60000-{nobody--} should be dynamic.

> and 500-700 never touched by the distribution.

I have a snapshot of a Gentoo system from 2004 (sys-apps/shadow-4.0.3-r9
and sys-apps/pam-login-3.14). Its login.defs has the following:

   #
   # Min/max values for automatic uid selection in useradd
   #
   UID_MIN                  1000
   UID_MAX                 60000

I see the same values in sys-apps/shadow/files/login.defs for the first
version of shadow in the tree (sys-apps/shadow-19990827-r1, committed on
2000-08-02).

So, I would conclude that Gentoo always used 1000 as minimum UID.

We could of course leave a gap for now, and allocate only 600..799.
This would leave the 500s for compatibility with very old systems.
It would have the additional advantage that we get an earlier warning
once the new range will be almost full. Even if we then allow IDs in the
60000s range, we presumably should keep some reserves of low IDs for
packages that really need them to be there.

Ulrich

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

>>>>> On Thu, 11 Nov 2021, Ulrich Mueller wrote:

> In any case, we have run out of GIDs:

>    Recommended GID only: none
>    Recommended UID only: 272
>    Recommended UID+GID pair: none
>    Free UIDs: 15
>    Free GIDs: 0
>    Free UID+GID pairs: 0

> The question is of course how we should move forward. Certainly, using
> IDs below 100 cannot be the solution, as we would run out of these very
> soon.

> We could:

> - Open some part of the range between 500 and 1000. For example,
>   500..799, which would leave 200 IDs for dynamic allocation.

> - Open part of the range 60001..65533. Not sure if all software will be
>   happy with that.

> - Admit that the concept of static allocation has failed, and return to
>   dynamic allocation.

By today's council decision, the whole range from 101 to 749 is now
available. The used_free_uidgids.sh script has been updated accordingly.

There seem to be some issues with system IDs above 60000 especially with
systemd. We'll try to sort these out before we run out of IDs again.

Ulrich

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Thomas Deutschmann]

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

On 2021-11-11 11:59, Ulrich Mueller wrote:
> We could:
> 
> - Open some part of the range between 500 and 1000. For example,
>    500..799, which would leave 200 IDs for dynamic allocation.
> 
> - Open part of the range 60001..65533. Not sure if all software will be
>    happy with that.
> 
> - Admit that the concept of static allocation has failed, and return to
>    dynamic allocation.

Only the third option is really possible.

The first option (500-1000) would be technically possible but would 
clash with knowledge people gained in the past and would violate LPIC 
(=making Gentoo even more special and unusable for companies relying on 
certifications).

In addition, it would just delay the problem we currently have and not 
solve/address it.

Allowing ranges 60001+ is technically not an option. Expect that daemons 
using IDs >1000 will run into problems. Expect security problems because 
known system user range is hardcoded in many places so 60001+ is 
unexpected. This will really make Gentoo 'unique' in a really bad way 
and will break with everything which is/was being taught/documented in 
the world.

Let's face it: The idea of static ID allocation didn't scale. Let's stop 
this experiment before it is too late. Like you know, I always ask why 
someone is proposing a change, i.e. asking for the motivation. The main 
driver behind static IDs was that when you are maintaining multiple 
systems, that if IDs are identical, it will make life a little bit 
easier because you could copy files from service A on system 1 to 
service A on system 2 without the need of adjusting permission 
afterwards. But is this really a problem? From my POV it isn't:

1) If this really was bothering you, you already had a solution in 
place. Keep in mind: Most setups don't just consist of 
Gentoo/Debian/RHEL-only... you usually have a mix of setups so you need 
a solution which works everywhere so you don't need that 'feature' 
Gentoo offered (not to mention that you probably have something like AD 
in place which will make things like that very easy).

2) Pay attention to the way how you do stuff today. You will not create 
systems manually anymore (and if you do, you would just clone so there 
isn't even a need for this). You will automate this in scripts and use 
tools like Ansible, Salt, Chef, Puppet.... and of course, Dockers (which 
is basically a script) and like mentioned, AD.

 From my POV I cannot imagine a single reason why we should stick to 
this idea and invest more time into it with the risk of making Gentoo 
more unique causing more _severe_ problems in future.

Anyone who wants to keep this around and wants to extend UID ranges 
instead should answer the following questions:

1) How are you going to solve the mentioned problems?

2) Why do you believe this feature is worth all the trouble?

3) At the moment we can stop. But once we start altering systems to mark 
additional ranges for system users there is _no_ easy way back anymore. 
Any blow up will probably require user to reinstall their entire system...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

>>>>> On Sun, 14 Nov 2021, Thomas Deutschmann wrote:

> On 2021-11-11 11:59, Ulrich Mueller wrote:
>> We could:
>> - Open some part of the range between 500 and 1000. For example,
>>   500..799, which would leave 200 IDs for dynamic allocation.
>> - Open part of the range 60001..65533. Not sure if all software will
>>   be happy with that.
>> - Admit that the concept of static allocation has failed, and return
>>   to dynamic allocation.

> Only the third option is really possible.

> The first option (500-1000) would be technically possible but would
> clash with knowledge people gained in the past and would violate LPIC 
> (=making Gentoo even more special and unusable for companies relying
> on certifications).

Why would that be? We chose the original split point quite arbitrarily
to be 500. What is different about adjusting it upwards now?

Ulrich

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Eray Aslan]

On Sun, Nov 14, 2021 at 09:15:36PM +0100, Thomas Deutschmann wrote:
> On 2021-11-11 11:59, Ulrich Mueller wrote:
> > We could:
> > 
> > - Open some part of the range between 500 and 1000. For example,
> >    500..799, which would leave 200 IDs for dynamic allocation.
> > 
> > - Open part of the range 60001..65533. Not sure if all software will be
> >    happy with that.
> > 
> > - Admit that the concept of static allocation has failed, and return to
> >    dynamic allocation.
> 
> Only the third option is really possible.

FWIW, I agree with this sentiment.

1/ Static allocation does not really solve a problem. Not really not
nowadays
2/ We cant keep adding new IDs to a distribution as new software gets
added - one side is unbounded.  This is losing game.

Switching back to dynamic allocation seems to be the best option.

-- 
Eray

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

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

On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> On Sun, Nov 14, 2021 at 09:15:36PM +0100, Thomas Deutschmann wrote:
> > On 2021-11-11 11:59, Ulrich Mueller wrote:
> > > We could:
> > > 
> > > - Open some part of the range between 500 and 1000. For example,
> > >    500..799, which would leave 200 IDs for dynamic allocation.
> > > 
> > > - Open part of the range 60001..65533. Not sure if all software will be
> > >    happy with that.
> > > 
> > > - Admit that the concept of static allocation has failed, and return to
> > >    dynamic allocation.
> > 
> > Only the third option is really possible.
> 
> FWIW, I agree with this sentiment.
> 
> 1/ Static allocation does not really solve a problem. Not really not
> nowadays
> 2/ We cant keep adding new IDs to a distribution as new software gets
> added - one side is unbounded.  This is losing game.
> 
> Switching back to dynamic allocation seems to be the best option.
> 
> -- 
> Eray
> 

I realize I'm very late to this party, but +1 from me also.

We should use dynamic uid/git assignment by default and maybe provide a
way to force certain uids/gids to be constant if users want this.

William

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Ulrich Mueller]

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

>>>>> On Sun, 28 Nov 2021, William Hubbs wrote:

> On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
>> 1/ Static allocation does not really solve a problem. Not really not
>> nowadays
>> 2/ We cant keep adding new IDs to a distribution as new software gets
>> added - one side is unbounded.  This is losing game.

Not sure. In practice, the number of packages is limited. (And if the
argument was valid, it would apply to dynamic alloction too.)

>> Switching back to dynamic allocation seems to be the best option.

> I realize I'm very late to this party, but +1 from me also.

> We should use dynamic uid/git assignment by default and maybe provide
> a way to force certain uids/gids to be constant if users want this.

While the rationale for static allocation that made it into GLEP 81 [1]
is rather weak, several people had argued in favour of it on the mailing
list [2].

In any case, let's cross that bridge when we reach it. For now, we're
good with 250 additional IDs.

Ulrich

[1] https://www.gentoo.org/glep/glep-0081.html#rationale
[2] https://archives.gentoo.org/gentoo-dev/message/33903763d46d193a25e4c03c4851bfc3

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

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

On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> >>>>> On Sun, 28 Nov 2021, William Hubbs wrote:
> 
> > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> >> 1/ Static allocation does not really solve a problem. Not really not
> >> nowadays
> >> 2/ We cant keep adding new IDs to a distribution as new software gets
> >> added - one side is unbounded.  This is losing game.
> 
> Not sure. In practice, the number of packages is limited. (And if the
> argument was valid, it would apply to dynamic alloction too.)
> 
> >> Switching back to dynamic allocation seems to be the best option.
> 
> > I realize I'm very late to this party, but +1 from me also.
> 
> > We should use dynamic uid/git assignment by default and maybe provide
> > a way to force certain uids/gids to be constant if users want this.
> 
> While the rationale for static allocation that made it into GLEP 81 [1]
> is rather weak, several people had argued in favour of it on the mailing
> list [2].
> 
> In any case, let's cross that bridge when we reach it. For now, we're
> good with 250 additional IDs.

It is inevitable that we will reach this bridge again -- whether or not
it is in a month or a year, it will happen.

Why are we just kicking the can down the road instead of admitting that
static allocation wasn't a good idea and going back to dynamic
allocation? Let's find out what the people who argued for static
allocation think.

William

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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Michał Górny]

On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > 
> > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > nowadays
> > > > 2/ We cant keep adding new IDs to a distribution as new software gets
> > > > added - one side is unbounded.  This is losing game.
> > 
> > Not sure. In practice, the number of packages is limited. (And if the
> > argument was valid, it would apply to dynamic alloction too.)
> > 
> > > > Switching back to dynamic allocation seems to be the best option.
> > 
> > > I realize I'm very late to this party, but +1 from me also.
> > 
> > > We should use dynamic uid/git assignment by default and maybe provide
> > > a way to force certain uids/gids to be constant if users want this.
> > 
> > While the rationale for static allocation that made it into GLEP 81 [1]
> > is rather weak, several people had argued in favour of it on the mailing
> > list [2].
> > 
> > In any case, let's cross that bridge when we reach it. For now, we're
> > good with 250 additional IDs.
> 
> It is inevitable that we will reach this bridge again -- whether or not
> it is in a month or a year, it will happen.
> 
> Why are we just kicking the can down the road instead of admitting that
> static allocation wasn't a good idea and going back to dynamic
> allocation? Let's find out what the people who argued for static
> allocation think.
> 

Why are you assuming that something "wasn't a good idea" just because
you think so?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

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

On Sun, Nov 28, 2021 at 08:15:13PM +0100, Michał Górny wrote:
> On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> > On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > > 
> > > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > > nowadays
> > > > > 2/ We cant keep adding new IDs to a distribution as new software gets
> > > > > added - one side is unbounded.  This is losing game.
> > > 
> > > Not sure. In practice, the number of packages is limited. (And if the
> > > argument was valid, it would apply to dynamic alloction too.)
> > > 
> > > > > Switching back to dynamic allocation seems to be the best option.
> > > 
> > > > I realize I'm very late to this party, but +1 from me also.
> > > 
> > > > We should use dynamic uid/git assignment by default and maybe provide
> > > > a way to force certain uids/gids to be constant if users want this.
> > > 
> > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > is rather weak, several people had argued in favour of it on the mailing
> > > list [2].
> > > 
> > > In any case, let's cross that bridge when we reach it. For now, we're
> > > good with 250 additional IDs.
> > 
> > It is inevitable that we will reach this bridge again -- whether or not
> > it is in a month or a year, it will happen.
> > 
> > Why are we just kicking the can down the road instead of admitting that
> > static allocation wasn't a good idea and going back to dynamic
> > allocation? Let's find out what the people who argued for static
> > allocation think.
> > 
> 
> Why are you assuming that something "wasn't a good idea" just because
> you think so?

ulm and others on the thread also mentioned the possibility of going
back to dynamic allocation, so it isn't just me who brought it up.

I honestly am just looking for a discussion.

Do other distros statically allocate all of their system users? If not,
why do we by default? I understand why enterprise users might need to,
and they can with the glep 81 eclasses by setting uids/gids in
make.conf, but is there a reason we force the issue at the distro level
and ban -1 as the setting for ACCT_USER_ID and ACCT_GROUP_ID?

William


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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

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

On Sun, Nov 28, 2021 at 02:46:24PM -0600, William Hubbs wrote:
> On Sun, Nov 28, 2021 at 08:15:13PM +0100, Michał Górny wrote:
> > On Sun, 2021-11-28 at 13:06 -0600, William Hubbs wrote:
> > > On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > > > > > > > > On Sun, 28 Nov 2021, William Hubbs wrote:
> > > > 
> > > > > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> > > > > > 1/ Static allocation does not really solve a problem. Not really not
> > > > > > nowadays
> > > > > > 2/ We cant keep adding new IDs to a distribution as new software gets
> > > > > > added - one side is unbounded.  This is losing game.
> > > > 
> > > > Not sure. In practice, the number of packages is limited. (And if the
> > > > argument was valid, it would apply to dynamic alloction too.)
> > > > 
> > > > > > Switching back to dynamic allocation seems to be the best option.
> > > > 
> > > > > I realize I'm very late to this party, but +1 from me also.
> > > > 
> > > > > We should use dynamic uid/git assignment by default and maybe provide
> > > > > a way to force certain uids/gids to be constant if users want this.
> > > > 
> > > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > > is rather weak, several people had argued in favour of it on the mailing
> > > > list [2].
> > > > 
> > > > In any case, let's cross that bridge when we reach it. For now, we're
> > > > good with 250 additional IDs.
> > > 
> > > It is inevitable that we will reach this bridge again -- whether or not
> > > it is in a month or a year, it will happen.
> > > 
> > > Why are we just kicking the can down the road instead of admitting that
> > > static allocation wasn't a good idea and going back to dynamic
> > > allocation? Let's find out what the people who argued for static
> > > allocation think.
> > > 
> > 
> > Why are you assuming that something "wasn't a good idea" just because
> > you think so?
> 
> ulm and others on the thread also mentioned the possibility of going
> back to dynamic allocation, so it isn't just me who brought it up.
> 
> I honestly am just looking for a discussion.
> 
> Do other distros statically allocate all of their system users? If not,
> why do we by default? I understand why enterprise users might need to,
> and they can with the glep 81 eclasses by setting uids/gids in
> make.conf, but is there a reason we force the issue at the distro level
> and ban -1 as the setting for ACCT_USER_ID and ACCT_GROUP_ID?
> 
> William
> 


Ok, based on floppym's response, I'm going to start a new thread.

William


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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Michael Orlitzky]

On 2021-11-28 11:06:36, Ulrich Mueller wrote:
> 
> While the rationale for static allocation that made it into GLEP 81 [1]
> is rather weak, several people had argued in favour of it on the mailing
> list [2].
> 

We don't even do static allocation. The UIDs and GIDs in the ebuilds
are suggestions, meant to benefit the people who will benefit from
them, and be ignored by everyone else.

There are a few exceptional cases where a user or group needs a
specific identifier; but those were always statically allocated and
nothing has changed in that regard.

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

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

On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> On 2021-11-28 11:06:36, Ulrich Mueller wrote:
> > 
> > While the rationale for static allocation that made it into GLEP 81 [1]
> > is rather weak, several people had argued in favour of it on the mailing
> > list [2].
> > 
> 
> We don't even do static allocation. The UIDs and GIDs in the ebuilds
> are suggestions, meant to benefit the people who will benefit from
> them, and be ignored by everyone else.
> 
> There are a few exceptional cases where a user or group needs a
> specific identifier; but those were always statically allocated and
> nothing has changed in that regard.

Doesn't the emerge fail if a different user with ACCT_USER_ID already exists on
the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa policy)?

If that's the case I don't see how we aren't doing static allocation.

William


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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Mike Gilbert]

On Sun, Nov 28, 2021 at 3:26 PM William Hubbs <williamh@gentoo.org> wrote:
>
> On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> > On 2021-11-28 11:06:36, Ulrich Mueller wrote:
> > >
> > > While the rationale for static allocation that made it into GLEP 81 [1]
> > > is rather weak, several people had argued in favour of it on the mailing
> > > list [2].
> > >
> >
> > We don't even do static allocation. The UIDs and GIDs in the ebuilds
> > are suggestions, meant to benefit the people who will benefit from
> > them, and be ignored by everyone else.
> >
> > There are a few exceptional cases where a user or group needs a
> > specific identifier; but those were always statically allocated and
> > nothing has changed in that regard.
>
> Doesn't the emerge fail if a different user with ACCT_USER_ID already exists on
> the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa policy)?

Not by default. If the eclass finds that ACCT_USER_ID is already
taken, it will allow useradd to assign a different one.

This behavior can be overridden by ebuilds (or a user) by setting
ACCT_USER_ENFORCE_ID.

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Gordon Pettey]

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

On Sun, Nov 28, 2021 at 2:27 PM William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> > We don't even do static allocation.

> There are a few exceptional cases where a user or group needs a
> > specific identifier; but those were always statically allocated and
> > nothing has changed in that regard.
>
> Doesn't the emerge fail if a different user with ACCT_USER_ID already
> exists on
> the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa
> policy)?
>
> If that's the case I don't see how we aren't doing static allocation.
>

User PoV when I see a bunch of acct-* packages pop up in emerge @world
updates:

A bunch of of acct-* ebuilds make claims for specific uid/gid for
applications
that don't have a reason I can think of to be requiring a specific number,
and
would never be used in a way (e.g. NFS-shared /etc) where the numeric
value actually matters.

[-- Attachment #2: Type: text/html, Size: 1498 bytes --]

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[William Hubbs]

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

On Sun, Nov 28, 2021 at 02:42:23PM -0600, Gordon Pettey wrote:
> On Sun, Nov 28, 2021 at 2:27 PM William Hubbs <williamh@gentoo.org> wrote:
> 
> > On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote:
> > > We don't even do static allocation.
> 
> > There are a few exceptional cases where a user or group needs a
> > > specific identifier; but those were always statically allocated and
> > > nothing has changed in that regard.
> >
> > Doesn't the emerge fail if a different user with ACCT_USER_ID already
> > exists on
> > the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa
> > policy)?
> >
> > If that's the case I don't see how we aren't doing static allocation.
> >
> 
> User PoV when I see a bunch of acct-* packages pop up in emerge @world
> updates:
> 
> A bunch of of acct-* ebuilds make claims for specific uid/gid for
> applications
> that don't have a reason I can think of to be requiring a specific number,
> and
> would never be used in a way (e.g. NFS-shared /etc) where the numeric
> value actually matters.

That's because qa mandates that any acct-group/acct-user packages in the
tree must claim a uid/gid.

Ultimately, we will run out of uids/gids to claim.

William


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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

[Eray Aslan]

On Sun, Nov 28, 2021 at 11:06:36AM +0100, Ulrich Mueller wrote:
> > On Mon, Nov 15, 2021 at 09:36:32AM +0300, Eray Aslan wrote:
> >> 1/ Static allocation does not really solve a problem. Not really not
> >> nowadays
> >> 2/ We cant keep adding new IDs to a distribution as new software gets
> >> added - one side is unbounded.  This is losing game.
> 
> Not sure. In practice, the number of packages is limited. (And if the
> argument was valid, it would apply to dynamic alloction too.)

In the static allocation option, the rate of increase is the rate of new
ID-needing software ported to the tree minus - optimistically - the rate
of treecleaning similar software.  Optimistic because I am not sure how
much, or at what point, do we want to re-use treecleaned IDs.

In the dynamic case, we dont care about the global status and are really
bound by the max number of sysem IDs installed in a single system.
Local maximum is rather stable and in any case is a lot smaller than
global maximum.  Plus in this age of containers and namespaces, this
isnt really a problem even if it did grow over time, i.e. even if
unbounded, we have tools to manage it.

-- 
Eray