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
We could:
- Open some part of the range between 500 and 1000. For example,
500..799, which would leave 200 IDs for dynamic allocation.
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.
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?
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'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-bitUID/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).
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.
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 toPersonally I would move to >60000 and keep the 300 additional IDs for the case
above 60000 immediately, or alternatively, give up the whole concept.
Ulrich
some software really really needs them
60000 up to where? 65533? I'll need to make a "hole" in ourallocations but that's perfectly do-able. Others may run into similar
=2^31, but that will again fail on systems that still use 16-bitUID/GID values (I'm not aware that we still support kernels older than 2.4).
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
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.
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.
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.
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?
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.
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.
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).
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.
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
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.
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.
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.
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].
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.
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)?
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.
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.
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?
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.
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
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.)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 486 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 144:28:19 |
| Calls: | 9,659 |
| Calls today: | 1 |
| Files: | 13,708 |
| Messages: | 6,167,838 |