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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 989EC1382C5 for ; Mon, 4 Jan 2021 03:18:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93A70E0946; Mon, 4 Jan 2021 03:18:55 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 555F9E0936 for ; Mon, 4 Jan 2021 03:18:55 +0000 (UTC) Subject: Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default To: gentoo-dev@lists.gentoo.org References: <20210104013558.20072-1-whissi@gentoo.org> From: Michael Orlitzky Message-ID: <60fac781-e080-999c-e83e-c657d5b89d18@gentoo.org> Date: Sun, 3 Jan 2021 22:18:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 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 In-Reply-To: <20210104013558.20072-1-whissi@gentoo.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: cb2f0b6f-cbfc-4b7d-bc33-be0a56272f96 X-Archives-Hash: 1082692e4e76b271f1389c62856a1221 On 1/3/21 8:35 PM, Thomas Deutschmann wrote: > Modifying an existing user is a bad default and makes Gentoo > special because it is common for system administrators to make > modifications to user (i.e. putting an user into another service's > group to allow that user to access service in question) and it > would be unexpected to see these changes reverted during normal > world upgrade (which could break services). It would be nice if this was well-supported by the official way of modifying system users/groups; that is, by using an overlay with modified user/group ebuilds. Right now it's awkward to do because of the way the eclasses are structured. For example, some of our servers allow the "postfix" user to write to OpenDKIM's socket, but only on our *outgoing* mail servers (not on the incoming MX, where no signing takes place.) This is accomplished by creating an acct-group/dkimsocket ebuild (ok so far), and then by overriding the acct-user/postfix ebuild: EAPI=7 inherit acct-user DESCRIPTION="user for postfix daemon" IUSE="dkimsocket" ACCT_USER_ID=207 ACCT_USER_GROUPS=( postfix mail ) acct-user_add_deps # This needs to be done outside of acct-user_add_deps because we can't # test use flags in global scope, and therefore we can't add groups # to ACCT_USER_GROUPS before calling acct-user_add_deps. RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )" pkg_setup() { # https://wiki.gentoo.org/wiki/OpenDKIM # # Even though we added the group to RDEPEND manually, we still # need to add it to the array. if use dkimsocket; then ACCT_USER_GROUPS+=( dkimsocket ) fi } That's the common case of adding a system user to a group, and it's pretty ugly, so it's no wonder that people want to use "usermod" and then ignore subsequent changes by the PM. And there's probably a backwards-compatible way we could support USE-conditional supplementary groups.