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 641FA1382C5 for ; Mon, 4 Jan 2021 07:33:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 67439E093E; Mon, 4 Jan 2021 07:32:57 +0000 (UTC) Received: from smtp.gentoo.org (dev.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 C1897E0935 for ; Mon, 4 Jan 2021 07:32:56 +0000 (UTC) Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 873F634096C for ; Mon, 4 Jan 2021 07:32:55 +0000 (UTC) Received: (qmail 26418 invoked by uid 10000); 4 Jan 2021 07:32:54 -0000 Date: Mon, 4 Jan 2021 07:32:54 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default Message-ID: References: <20210104013558.20072-1-whissi@gentoo.org> 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-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aAYbr14jHAy2Yyau" Content-Disposition: inline In-Reply-To: <20210104013558.20072-1-whissi@gentoo.org> X-Archives-Salt: 4e06ad96-157f-4824-9a12-9014a80af094 X-Archives-Hash: 59efbc3ade0d720a66b2d56bfb524718 --aAYbr14jHAy2Yyau Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Whissi's patch in itself is a good step forward, but I don't feel it goes far enough, nor promotes better defaults for the unmodified cases. On Mon, Jan 04, 2021 at 02:35:58AM +0100, 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). >=20 > This commit will make Gentoo behave like any other Linux distribution > by respecting any user modifications by default. However, we will retain > the functionality to reset system user and groups and users interested > in this feature can opt-in by setting > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in > their make.conf. No default is good, and that's the mess here. The problem has started to happen in other distros as well, not just Gentoo. usermod/gpasswd in RPM specfiles, as well as Debian controls. As a sysadmin, I don't want stuff messing with the system users I have in place; but if upstream requirements change on a package impacting user/group layout, I also expect packaging to track it. Many years ago, qmail did this, introducing an additional user to further separate privileges. Unfortunately, these two things are in conflict, and I don't feel there is an easy answer. It's NOT the binary decision of: - let packagers change system user - force sysadmins to always change users manually Nor a single knob that selects between that binary. We need a compromise. The best I can come up with at the moment, is that any packaging should detect if there are user modifications, and provide control to users based on that fact. - if unmodified: interactive, or auto-accept, or deny - if modified: interactive, or auto-accept, or deny These are two distinct config knobs (I'm ok with a default value that populates both of them). This leads to secondary parts: - what if the packaging change regarding users/groups is absolutely mandatory for the new version of a package to work correctly? - what about conflicting user requirements? Antarus raised the HOMEDIR of the git user for gitolite vs gitea. I think in this case, the packages should detect the problematic conditions and abort, in pkg_pretend and/or pkg_setup (thinking about binpkgs here, pkg_pretend might be too early if acct-user/X needs to merged before the check is expected to succeed). These checks MUST be in the package that consumes/depends on acct-user or acct-group packages. Yes, this means constants are likely to be duplicated, but I'm ok with that, because they are also likely to be specifically versioned. --=20 Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robbat2@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 --aAYbr14jHAy2Yyau Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it. iQKTBAABCgB9FiEEveu2pS8Vb98xaNkRGTlfI8WIJsQFAl/yxKRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJE RUJCNkE1MkYxNTZGREYzMTY4RDkxMTE5Mzk1RjIzQzU4ODI2QzQACgkQGTlfI8WI JsQ0nQ//WlCd9w7d5cIueSVH2PTdMXVyryKHNtJX7WszYdeULYJapZJh88upmHPa LW9DPko6QE1uGjS8GQr0/MTm2/rEe3M3yRh2YQoTys4AUBiwWsccc65SqrsCo6cd XrTgVK3g7+1xwnBCFabpxmf/fVmI3BW/QFZ0Mjb5Ty6FglFKCxAPX17tBlXyqO5f ELtUIrZy8Tcfa+ltVVQ5XySjQO7l+3RIHaVcwXW4M+/dHKxUGIs17nQq0lp6CSe1 sx9hNgqi1uATSs0wkeyRcQcwdEV/sdu07JOtyQmAywJlOpYr/d5o+0m5Sv3vOqaQ EDnqyXtFkR+B96tjug5WOBXM0Qj9YgYtki0otH8z7jMqZTGZ7SQhOfyvvW5/FcfY tKpfXT72o/rw6e+sP5TetDDG73MinK6JbYvWP4FKawx/uQnnRyeMZnqznn83+Kvj xgYieT3P34J+YIYW11lNdSchbT0mWLiCfAsQQy+R/elvssHlPVeLp7HXVho3OihG Icq/w04XtlBtIWbTOImJNx/J2Y3p4m4vIx8oMOg2G/6fctE5f35V37gqyN5e/KVD TaH+01+t/1l6NkwWJZFoLn7YPq1kHJ/b5LfzSmR+bA3oILVxsZv9JfY1zsFX4rPL Dcalyt9ZMIpbMdOttrKZprUSVCAw+4BXn5jFHGjNL6ZWAI/vOgY= =iGtM -----END PGP SIGNATURE----- --aAYbr14jHAy2Yyau--