From: Alec Warner <antarus@gentoo.org>
To: Gentoo Dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Date: Sun, 3 Jan 2021 19:17:40 -0800 [thread overview]
Message-ID: <CAAr7Pr8-6rHNBud0OVUUvvXYttCoVPgXbmD+aHVEmnRAbhwFXQ@mail.gmail.com> (raw)
In-Reply-To: <CAJ0EP4284i-QcppTyjz4+O3i1p2RbZbMUW-WhzK5_CjGnnhjBw@mail.gmail.com>
On Sun, Jan 3, 2021 at 6:42 PM Mike Gilbert <floppym@gentoo.org> wrote:
>
> On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann <whissi@gentoo.org> 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.
>
next prev parent reply other threads:[~2021-01-04 3:17 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-04 1:35 [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default Thomas Deutschmann
2021-01-04 2:41 ` Mike Gilbert
2021-01-04 3:17 ` Alec Warner [this message]
2021-01-04 3:18 ` Michael Orlitzky
2021-01-04 14:46 ` Thomas Deutschmann
2021-01-04 15:24 ` Michael Orlitzky
2021-01-04 15:55 ` David Seifert
2021-01-04 16:18 ` Thomas Deutschmann
2021-01-04 16:28 ` Michał Górny
2021-01-04 16:30 ` Thomas Deutschmann
2021-01-04 16:34 ` Thomas Deutschmann
2021-01-04 16:38 ` Michał Górny
2021-01-04 16:50 ` Thomas Deutschmann
2021-01-04 16:56 ` Michał Górny
2021-01-04 16:56 ` Mike Gilbert
2021-01-04 16:54 ` Mike Gilbert
2021-01-04 7:32 ` Robin H. Johnson
2021-01-04 16:45 ` [gentoo-dev] " James Cloos
2021-01-04 18:07 ` Michael Orlitzky
2021-01-04 18:20 ` Michał Górny
2021-01-04 18:38 ` Michael Orlitzky
2021-01-04 18:23 ` Thomas Deutschmann
2021-01-04 18:27 ` Michael Orlitzky
2021-01-04 18:32 ` Thomas Deutschmann
2021-01-04 9:23 ` [gentoo-dev] " Michał Górny
2021-01-04 14:05 ` Thomas Deutschmann
2021-01-04 16:10 ` Mike Gilbert
2021-01-04 16:14 ` Michał Górny
2021-01-04 16:20 ` Thomas Deutschmann
2021-01-08 18:11 ` Fabian Groffen
2021-01-08 18:14 ` Michał Górny
2021-01-08 18:23 ` Thomas Deutschmann
2021-01-08 18:32 ` Michał Górny
2021-01-08 15:48 ` Thomas Deutschmann
2021-01-08 16:03 ` Mike Gilbert
2021-01-08 16:29 ` Thomas Deutschmann
2021-01-08 16:50 ` Mike Gilbert
2021-01-08 17:06 ` Mike Gilbert
2021-01-08 18:10 ` Thomas Deutschmann
2021-01-08 18:31 ` Michał Górny
2021-01-08 19:15 ` Mike Gilbert
2021-01-08 17:16 ` Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAr7Pr8-6rHNBud0OVUUvvXYttCoVPgXbmD+aHVEmnRAbhwFXQ@mail.gmail.com \
--to=antarus@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox