<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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
