On 1/3/21 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).
It would be nice if this was well-supported by the official way of
modifying system users/groups; that is, by using an overlay with
modified user/group ebuilds.
Right now it's awkward to do because of the way the eclasses are
structured. For example, some of our servers allow the "postfix" user to
write to OpenDKIM's socket, but only on our *outgoing* mail servers (not
on the incoming MX, where no signing takes place.) This is accomplished
by creating an acct-group/dkimsocket ebuild (ok so far), and then by
overriding the acct-user/postfix ebuild:
EAPI=7
inherit acct-user
DESCRIPTION="user for postfix daemon"
IUSE="dkimsocket"
ACCT_USER_ID=207
ACCT_USER_GROUPS=( postfix mail )
acct-user_add_deps
# This needs to be done outside of acct-user_add_deps because we can't
# test use flags in global scope, and therefore we can't add groups
# to ACCT_USER_GROUPS before calling acct-user_add_deps.
RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )"
pkg_setup() {
# https://wiki.gentoo.org/wiki/OpenDKIM
#
# Even though we added the group to RDEPEND manually, we still
# need to add it to the array.
if use dkimsocket; then
ACCT_USER_GROUPS+=( dkimsocket )
fi
}
That's the common case of adding a system user to a group, and it's
pretty ugly, so it's no wonder that people want to use "usermod" and
then ignore subsequent changes by the PM.
And there's probably a backwards-compatible way we could support
USE-conditional supplementary groups.
