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 <[email protected]> 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 <[email protected]> > > > 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
signature.asc
Description: Digital signature
