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

[Alec Warner]

On Tue, May 28, 2019 at 11:05 AM Mike Gilbert <floppym@g.o> wrote:

> On Tue, May 28, 2019 at 10:43 AM William Hubbs <williamh@g.o>
> wrote:
> >
> > 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.
>
> Your kubernetes example is not a very compelling one. Firstly, none of
> the kubernetes-related ebuilds in the gentoo repo actually call
> enewuser or enewgroup with a static id. Secondly, I would expect the
> sysadmin of a kubernetes cluster to allocate a UID/GID range outside
> the "system range" defined in /etc/login.defs.
>
> > > 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.
>
> If you are running a cluster system that requires static ids, you
> should really create these ids yourself as part of the cluster node
> setup process.
>

Pretty much +1 to this. I agree this is a problem as many services use
shared uid / gid to handle authorization. I'm not convinced solving this
problem at the package manager level is correct, so every time its proposed
I vote no.

If you need to share UID / GID, across hosts, there are many solutions
available.
 - lib_nssldap
 - lib_nsscache
 - lib_nssfiles with configuration management on top.

These are all strictly better than trying to do this in ebuilds.

-A