From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C09CE158086 for ; Mon, 29 Nov 2021 13:25:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F16FA2BC064; Mon, 29 Nov 2021 13:25:34 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4C3A42BC032 for ; Mon, 29 Nov 2021 13:25:34 +0000 (UTC) Message-ID: <62ee1e6ddf56bdcb3400eb162509ab094a9c9999.camel@gentoo.org> Subject: Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo From: Michael Orlitzky To: gentoo-dev@lists.gentoo.org Date: Mon, 29 Nov 2021 08:25:30 -0500 In-Reply-To: <121470D9-30EF-43FC-B085-6C51AE6C0496@gentoo.org> References: <4accff715fedc3c142bdb67e4b52cfc0cfd6bb4a.camel@gentoo.org> <8B541414-A752-4668-AA72-EC3AEEC870C3@gentoo.org> <121470D9-30EF-43FC-B085-6C51AE6C0496@gentoo.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Archives-Salt: d0fe839d-f2bb-4851-b828-aa6e6fcaedbd X-Archives-Hash: 9c65da6c956954b97e0ce2e86af48613 On Mon, 2021-11-29 at 05:05 +0000, Sam James wrote: > > What I wish we had done (and there's still time to do, albeit belated -- > it's still useful for the remaining big bits like Apache and nginx) is > write a news item explaining the implications and linked to a page > like https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration > (which ConiKost created after we discussed how to inform users better) > that explains how to work around/express their preferences/give their own hints. > I agree, and there's still room to improve the user interface as well. For example, I run postfix on all of my machines. A few of them also need to run OpenDKIM, and need the postfix user to be a member of a group that is shared with OpenDKIM, to access a socket. To best integrate with the PM, the solution to this problem is to override acct-user/postfix in an overlay. Ok, no problem. But since the additional group should be optional, it needs to be controlled by a USE flag if you want to use the same ebuild across your entire organization. The implementation details make this a bit ugly: RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )" pkg_setup() { if use dkimsocket; then ACCT_USER_GROUPS+=( dkimsocket ) fi } The extra noise is necessary because "dkimsocket" needs to be added to two arrays, and that can't be done declaratively at the moment. It would be a nice UI improvement if the best solution was less of a headache. > Sorry, I should've been explicit. The main thing I'd like to understand better > from your POV is: > > this isn't new, but you're quite clear you feel that the UID/GID range limitations > are completely arbitrary and without merit(?). > > Whissi essentially says the opposite: https://archives.gentoo.org/gentoo-dev/message/17a22877f5f18dae44a2f0859d807450 . > > I'd like to understand if this is just a result of beliefs about what the PM should/shouldn't do > or if there's genuine problems with continuing to extend the range? Using the rest of the system range (500-999) should pose no problems for anyone, since that's exactly what the old user.eclass will do. I also see no problem with 60001+. I'm skeptical that any daemons have those ranges hard-coded; and even if they do, they're buggy and we shouldn't handicap the distribution over it. More fundamentally, the "user" and "system" limits themselves not written in stone: they are written in login.defs, and are only hints for a few standard tools. Software should not be guessing at them. I think we should try to keep things as consistent as possible with other distributions, operating systems, and standards -- but if it comes down to it, the numbers in the acct-* ebuilds are only suggestions, and it doesn't hurt anything in the long run to suggest a number that might already be taken because login.defs allowed useradd to take it in the past.