Gentoo Archives: gentoo-dev

From: Mike Gilbert <floppym@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] [PATCH] user.eclass: die if hard coded UID or GID is already in use
Date: Tue, 28 May 2019 06:21:43
Message-Id: CAJ0EP42d8e1f=js-0sB_VKzvCTDy54m9cvSE7Xd=KAszF5fM-w@mail.gmail.com
In Reply to: Re: [gentoo-dev] [PATCH] user.eclass: die if hard coded UID or GID is already in use by "Robin H. Johnson"
1 On Tue, May 28, 2019 at 1:41 AM Robin H. Johnson <robbat2@g.o> wrote:
2 >
3 > On Mon, May 27, 2019 at 08:44:09PM -0400, Mike Gilbert wrote:
4 > > On Mon, May 27, 2019 at 11:45 AM William Hubbs <williamh@g.o> wrote:
5 > > >
6 > > > If a package hard codes the UID or GID when adding a user or group to
7 > > > the system and that UID/GID already exists, we should abort rather than
8 > > > changing the UID/GID.
9 > > These functions have behaved this way for a long time.
10 > Yes, I recall this breakage being raised even prior to GLEP27.
11 >
12 > Some coverage of prior work firstly.
13 > 2003/May: eid_database [1]
14 > 2004/May: GLEP27 [2]
15 > 2006/Summer: GSOC Project for GLEP27 implementation [3]
16 > Later: Creandus [4][5]
17 >
18 > [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-src/eid_database/
19 > [2] https://www.gentoo.org/glep/glep-0027.html
20 > [3] https://github.com/creandus/creandus.github.com/blob/master/glep27-proposal.txt
21 > [4] https://github.com/creandus/
22 > [5] http://creandus.github.io/
23 >
24 > > What problem are you trying to solve here?
25 > Specifically:
26 > 1. Package A is emerged, and the ebuild specifies enewuser/enewgroup
27 > with -1 as the numeric input, and some user or group is created with
28 > value X.
29 > 2. Package B is emerged, and the ebuild specifies enewuser/enewgroup
30 > with a fixed UID/GID value Y && explicitly depends on having that
31 > specific value.
32
33 Could you provide some examples of packages that require a specific
34 numeric UID/GID to function properly? That seems like a significant
35 design flaw.
36
37 > I'd like to accept WilliamH's patch as-is, and then add an additional
38 > patch that moves the range of dynamically allocated users such that it
39 > does not conflict.
40
41 The "dynamic range" currently defaults to 101 to 999 as defined by
42 SYS_{UID,GID}_{MIN,MAX} in /etc/login.defs. It is quite likely that
43 live production systems have ids scattered throughout this range.
44 Changing enewuser/enewgroup to fail if there are "conflicts" may make
45 some ebuilds unusable on said systems.
46
47 As mgorny suggests, I suspect the static UID/GID that is sometimes
48 passed to enewuser/enewgroup is more of a preference/suggestion than a
49 requirement.
50
51 I do not believe William's patch should be merged without some very
52 good reason for the change in behavior.

Replies