Gentoo Archives: gentoo-dev

From: Michael Orlitzky <mjo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
Date: Mon, 29 Nov 2021 13:25:40
Message-Id: 62ee1e6ddf56bdcb3400eb162509ab094a9c9999.camel@gentoo.org
In Reply to: Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo by Sam James
1 On Mon, 2021-11-29 at 05:05 +0000, Sam James wrote:
2 >
3 > What I wish we had done (and there's still time to do, albeit belated --
4 > it's still useful for the remaining big bits like Apache and nginx) is
5 > write a news item explaining the implications and linked to a page
6 > like https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration <https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration>
7 > (which ConiKost created after we discussed how to inform users better)
8 > that explains how to work around/express their preferences/give their own hints.
9 >
10
11 I agree, and there's still room to improve the user interface as well.
12 For example, I run postfix on all of my machines. A few of them also
13 need to run OpenDKIM, and need the postfix user to be a member of a
14 group that is shared with OpenDKIM, to access a socket.
15
16 To best integrate with the PM, the solution to this problem is to
17 override acct-user/postfix in an overlay. Ok, no problem. But since the
18 additional group should be optional, it needs to be controlled by a USE
19 flag if you want to use the same ebuild across your entire
20 organization. The implementation details make this a bit ugly:
21
22 RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )"
23
24 pkg_setup() {
25 if use dkimsocket; then
26 ACCT_USER_GROUPS+=( dkimsocket )
27 fi
28 }
29
30 The extra noise is necessary because "dkimsocket" needs to be added to
31 two arrays, and that can't be done declaratively at the moment. It
32 would be a nice UI improvement if the best solution was less of a
33 headache.
34
35
36
37 > Sorry, I should've been explicit. The main thing I'd like to understand better
38 > from your POV is:
39 >
40 > this isn't new, but you're quite clear you feel that the UID/GID range limitations
41 > are completely arbitrary and without merit(?).
42 >
43 > Whissi essentially says the opposite: https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450 <https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450>.
44 >
45 > I'd like to understand if this is just a result of beliefs about what the PM should/shouldn't do
46 > or if there's genuine problems with continuing to extend the range?
47
48 Using the rest of the system range (500-999) should pose no problems
49 for anyone, since that's exactly what the old user.eclass will do. I
50 also see no problem with 60001+. I'm skeptical that any daemons have
51 those ranges hard-coded; and even if they do, they're buggy and we
52 shouldn't handicap the distribution over it.
53
54 More fundamentally, the "user" and "system" limits themselves not
55 written in stone: they are written in login.defs, and are only hints
56 for a few standard tools. Software should not be guessing at them. I
57 think we should try to keep things as consistent as possible with other
58 distributions, operating systems, and standards -- but if it comes down
59 to it, the numbers in the acct-* ebuilds are only suggestions, and it
60 doesn't hurt anything in the long run to suggest a number that might
61 already be taken because login.defs allowed useradd to take it in the
62 past.