Re: [gentoo-dev] [PATCH] user.eclass: die if hard coded UID or GID is already in use

[William Hubbs]

On Tue, May 28, 2019 at 02:21:23AM -0400, Mike Gilbert wrote:
> On Tue, May 28, 2019 at 1:41 AM Robin H. Johnson <robbat2@g.o> wrote:
> >
> > On Mon, May 27, 2019 at 08:44:09PM -0400, Mike Gilbert wrote:
> > > On Mon, May 27, 2019 at 11:45 AM William Hubbs <williamh@g.o> wrote:
> > > >
> > > > If a package hard codes the UID or GID when adding a user or group to
> > > > the system and that UID/GID already exists, we should abort rather than
> > > > changing the UID/GID.
> > > These functions have behaved this way for a long time.
> > Yes, I recall this breakage being raised even prior to GLEP27.
> >
> > Some coverage of prior work firstly.
> > 2003/May: eid_database [1]
> > 2004/May: GLEP27 [2]
> > 2006/Summer: GSOC Project for GLEP27 implementation [3]
> > Later: Creandus [4][5]
> >
> > [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/eid_database/
> > [2] https://www.gentoo.org/glep/glep-0027.html
> > [3] https://github.com/creandus/creandus.github.com/blob/master/glep27-proposal.txt
> > [4] https://github.com/creandus/
> > [5] http://creandus.github.io/
> >
> > > What problem are you trying to solve here?
> > Specifically:
> > 1. Package A is emerged, and the ebuild specifies enewuser/enewgroup
> > with -1 as the numeric input, and some user or group is created with
> > value X.
> > 2.  Package B is emerged, and the ebuild specifies enewuser/enewgroup
> > with a fixed UID/GID value Y && explicitly depends on having that
> > specific value.
>
> Could you provide some examples of packages that require a specific
> numeric UID/GID to function properly? That seems like a significant
> design flaw.

The example I specifically found was kubernetes security contexts -- to
set one of these up, you need numeric uids/gids [1].

[1] https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

I agree this could be possibly seen as a flaw, but I don't know enough
about kubernetes to know if symbolic uids/gids could be used.

I am speculating here, but I'm guessing that if the pod spans
multiple hosts, the uids/gids might need to be the same, which would
require fixed UIDs/GIDs.

>
> > I'd like to accept WilliamH's patch as-is, and then add an additional
> > patch that moves the range of dynamically allocated users such that it
> > does not conflict.
>
> The "dynamic range" currently defaults to 101 to 999 as defined by
> SYS_{UID,GID}_{MIN,MAX} in /etc/login.defs. It is quite likely that
> live production systems have ids scattered throughout this range.
> Changing enewuser/enewgroup to fail if there are "conflicts" may make
> some ebuilds unusable on said systems.

Another part of this I want to do is audit all of the packages
requesting fixed UIDS/GIDS; they may not need to be doing so.

>
> As mgorny suggests, I suspect the static UID/GID that is sometimes
> passed to enewuser/enewgroup is more of a preference/suggestion than a
> requirement.
>
> I do not believe William's patch should be merged without some very
> good reason for the change in behavior.
 
Consider this situation:

in package-a.ebuild:
enewuser usera 300 ...
enewgroup groupa 300 ...

in package-b.ebuild:
enewuser userb 300 ...
enewgroup groupb 300 ...

Ok, cool, if I need a security context for package b, the uid/gid is 300
correct? Yes, unless package a gets installed on some host where package
b is without me knowing about it.

I see no way around this other than to make uids/gids fixed when
packages request specific ones.


William