Mailing List Archive

Don't use UIDs and GIDs below 100 without QA approval
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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
>>>>> 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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
>>>>> 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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
>>>>> 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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
>>>>> 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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
>>>>> 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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
>>>>> 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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
>>>>> 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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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
Re: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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: Don't use UIDs and GIDs below 100 without QA approval [ In reply to ]
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

1 2  View All