Mailing List Archive

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

1 2  View All