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.
> 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.
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.
