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 F3DAB1382C5 for ; Mon, 4 Jan 2021 03:17:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A45CE0931; Mon, 4 Jan 2021 03:17:53 +0000 (UTC) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 DF579E0923 for ; Mon, 4 Jan 2021 03:17:52 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id b9so35155100ejy.0 for ; Sun, 03 Jan 2021 19:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=T+Pmr+rsLDGq8FLPyh0WcJlMtyQ08ciM6Xc8hKu5j1c=; b=PoEj3v89DzRKlejwTEBXXBshXOdLxBeffyKS39mEwNTdgyvFLUHb4u4zbg9uzIM8dz 4YwzNejHku/PDpX5OsrMmi/kID/wiuT9EDPwknGft+Po7srELY1zzQP0VgfiSvjIU+LC /88AwPceKCTl9QV6AoBoDjCfrYqkGAZ4AVVMgU/F9MM/QNeBq0WBcsC/WYITsKLyYjEG jF5TOq2QDQKIYU+8H6EHbHVuvHV4sjNi1NlwINlWt0uM1kePZVq/owh3GXNO1nNrmrDV LP9BtVUI73qvJ/CuL3XeIQVqBIzzSvTRfnz7hEEHu1oPYICIKQ2qTJjXWImjk6Aa/j8G sA/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=T+Pmr+rsLDGq8FLPyh0WcJlMtyQ08ciM6Xc8hKu5j1c=; b=Vm12sJyDGv23nbOKzaSFBfplLpL6m63L6seHdbNCkGNI5VV1s6M49juXucSiqGBlfH kyn+gQpcUYtL6cSueRTNNb1vj2hVuoNPSm4jtlpbkcOgpi4VgpLEIChA9SBHxaKHKze+ 7RlinHudQlO96yC53XvlsBuELFPkWbOPR3SLtvYnKsedV8I+AfZQB/31W9cjez0luby6 UhXVUJ1wrk7zPI9X+PuDk7yjNgYF7PtlhHppLkuA9WyZzWG6qvBAcoXSwIXlPi1PUnmD GNRe2P/afBWobMcX8rlnk4gKo9oVnQXCvitBCSASihRQRshM0u7IAjFycIoJIzJnSfP3 dALg== X-Gm-Message-State: AOAM532xGONEdwDGbsTRtm2C7S4nW/VfrPC/D8wBicK7UhQu9QOGWuqN QpuoyGWQ62ZnIi2L39N1ICTB9Sa4hpVhVzrDWDhNyhlPEO/wZXTi X-Google-Smtp-Source: ABdhPJz+/0gPxGSSrbST+gmsdG0lIhypnoVtCU4Fq3/ZSeMAmmP6qq6ApsyEEVh6tTZl/6FXFDu0KTX0iOdxgqa2HLY= X-Received: by 2002:a17:906:6606:: with SMTP id b6mr63645052ejp.151.1609730271047; Sun, 03 Jan 2021 19:17:51 -0800 (PST) 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 References: <20210104013558.20072-1-whissi@gentoo.org> In-Reply-To: From: Alec Warner Date: Sun, 3 Jan 2021 19:17:40 -0800 Message-ID: Subject: Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default To: Gentoo Dev Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: ba96e0ef-eb4e-4948-862e-6d46a76f7bf7 X-Archives-Hash: 238bde0d0f1049142b7772393e11a55a On Sun, Jan 3, 2021 at 6:42 PM Mike Gilbert wrote: > > On Sun, Jan 3, 2021 at 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). > > > > 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. > > So the main problem I see with doing this is that it becomes > impossible to reliably make changes to a user in later ebuild > revisions. Developers may want/need to deploy changes to user > attributes. Changing group memberships seems like the best example, > but I could foresee a want/need to change DESCRIPTION, HOME, or SHELL > as well. I think the TL;DR is I don't believe changes in HOME, or SHELL are safe to do in later revisions. This means developers: - Need to be careful when picking em! - Can use later revisions to set sane defaults for fresh installs. - Can't touch existing installs because changing HOME and SHELL can cause user-facing breakage. Often if HOME points somewhere that isn't /dev/null, you have to do some kind of migration. I'd rather not enable that sort of breakage by default because it's a per-app / per-user migration pain. To pick an example: The git user has a HOME in either /var/lib/gitea or /var/lib/gitolite. If you change it, you will break whatever service is running. This is the same for any service account whose $HOME stores state...which is most of them with a HOME set. -A > > Because of this, I think the new behavior should be opt-in, and people > who use it should be aware that they will need to pay attention if any > account changes are rolled out in new ebuild versions. > > > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass > > index 22b0038fbff7..d60b1e53b4bb 100644 > > --- a/eclass/acct-user.eclass > > +++ b/eclass/acct-user.eclass > > @@ -309,6 +321,20 @@ acct-user_pkg_pretend() { > > fi > > } > > > > +# @FUNCTION: acct-user_pkg_setup > > +# @DESCRIPTION: > > +# Initialize internal environment variable(s). > > +acct-user_pkg_setup() { > > + debug-print-function ${FUNCNAME} "${@}" > > + > > + # check if user already exists > > + ACCT_USER_ALREADY_EXISTS= > > + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then > > + ACCT_USER_ALREADY_EXISTS=yes > > + fi > > + readonly ACCT_USER_ALREADY_EXISTS > > +} > > I don't think this pkg_setup function is necessary; you could do this > in pkg_preinst instead, before enewuser gets called. >