Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

[Robin H. Johnson]

<warning type="bikeshed">

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).
>
> 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.

</warning>

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@g.o
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136