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

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

[Thomas Deutschmann]

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.

Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>
---
 eclass/acct-user.eclass | 40 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 38 insertions(+), 2 deletions(-)

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
@@ -72,6 +72,11 @@ readonly ACCT_USER_NAME
 # Overlays should set this to -1 to dynamically allocate UID.  Using -1
 # in ::gentoo is prohibited by policy.
 
+# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
+# @INTERNAL
+# @DESCRIPTION:
+# Status variable which indicates if user already exists.
+
 # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID
 # @DESCRIPTION:
 # If set to a non-null value, the eclass will require the user to have
@@ -79,6 +84,13 @@ readonly ACCT_USER_NAME
 # the UID is taken by another user, the install will fail.
 : ${ACCT_USER_ENFORCE_ID:=}
 
+# @ECLASS-VARIABLE: ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED
+# @DESCRIPTION:
+# If set to a non-null value, the eclass is allowed to make changes
+# to an already existing user which will include overriding any
+# changes made by system administrator.
+: ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED:=}
+
 # @ECLASS-VARIABLE: ACCT_USER_SHELL
 # @DESCRIPTION:
 # The shell to use for the user.  If not specified, a 'nologin' variant
@@ -266,8 +278,8 @@ eunlockuser() {
 
 
 # << Phase functions >>
-EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst pkg_postinst \
-	pkg_prerm
+EXPORT_FUNCTIONS pkg_pretend pkg_setup src_install pkg_preinst \
+	pkg_postinst pkg_prerm
 
 # @FUNCTION: acct-user_pkg_pretend
 # @DESCRIPTION:
@@ -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
+}
+
 # @FUNCTION: acct-user_src_install
 # @DESCRIPTION:
 # Installs a keep-file into the user's home directory to ensure it is
@@ -379,6 +405,16 @@ acct-user_pkg_postinst() {
 		return 0
 	fi
 
+	if [[ -z ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED} && -n ${ACCT_USER_ALREADY_EXISTS} ]] ; then
+		eunlockuser "${ACCT_USER_NAME}"
+
+		einfo "User ${ACCT_USER_NAME} already exists; Not touching existing user."
+		einfo "NOTE: If you want to allow package manager to reset user settings"
+		einfo "      like home, shell, groups... set ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED"
+		einfo "      to a non-null value in your make.conf."
+		return 0
+	fi
+
 	# NB: eset* functions check current value
 	esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
 	esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"
-- 
2.30.0

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

[Mike Gilbert]

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.

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.

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

[Alec Warner]

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

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

[Michael Orlitzky]

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.

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

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 3158 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

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

[Michał Górny]

On Mon, 2021-01-04 at 02:35 +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).

Not modifying an existing user is a horrible default that has already
bricked one system (by removing /dev/null).  So, over my dead commit
access.

-- 
Best regards,
Michał Górny

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

[Thomas Deutschmann]

On 2021-01-04 10:23, Michał Górny wrote:
> Not modifying an existing user is a horrible default that has already
> bricked one system (by removing /dev/null).  So, over my dead commit
> access.

Have you seen how many user were hit caused by the recent rebuilt on 
2020-12-28 and are already complaining/asking for help through various 
channels?

It's like asking for service auto-restart support in PMS as requested as 
part of current OpenSSH upgrade because if you move from <8.3_p1 to 
 >=8.3_p1 and don't restart OpenSSH in time, you can get locked out.

However, an easily looking solution like

> Just add something like
> 
> 	if [[ -d /run/systemd/system ]]; then
> 			systemctl try-restart sshd
> 	else
> 			rc-service -q --ifstarted sshd restart
> 	fi
> 
> to pkg_postinst

is wrong because even if it works for *some* users it won't work for all 
users but has the potential to cause major problems.

That's why we have elog and newitem system. However, 8.3 is in 
repository for while and multiple people forgot about the newitem and 
didn't pay attention to elog messages. While I agree that it's a problem 
when you lose access to a remote box you don't have physical access to, 
this reached a level where I have to say,

 > We cannot rescue/protect everyone.

Back to topic, acct-* stuff:

Like already said in February 2020 when I joined a thread created by a 
user posting same concerns:

There is a reason why *no* distribution on this planet is trying to mess 
with existing data/configurations: Every attempt trying to analyze given 
setup to apply required changes to fix/migrate something automatically 
has been prone to fail the long run.

Please get some experience from real world. Preferable from running 
headless systems not just for yourself and where you are not the only 
person touching the system.

When I worked on bug 605008 long time ago for example, I also ended up 
over-engineering. There is stuff you cannot fix. I am still thinking 
about creating everything the way it should look like in $D and report 
any difference like changed file permissions to user on merge to allow 
them to notice (an improvement, now user only have to pay attention and 
you need to solve the additional problem that the more information you 
present all the time, the more information will be ignored). But 
sometimes users are making changes we wouldn't do, not recommend or just 
don't understand at first. That all doesn't matter: We have to keep in 
mind that these aren't our systems and we have to respect whatever the 
user did on their system.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

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

[Thomas Deutschmann]

Hi,

On 2021-01-04 04:18, Michael Orlitzky wrote:
> 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.

No, this doesn't work:

1) It's conflicting with the goals other have. See Mike's first reply to 
my patch proposal:

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

He is obviously looking for a way to allow maintainers to change users 
afterwards. But if we tell people, "If you need customization, fork the 
user/group ebuild in your overlay" we will disconnect these users from 
future changes.


2) Thank you for outlining the process how to make changes to users 
using the new acct-* way. It's a nice 'hack'. But it is an own, new way, 
which makes Gentoo special, unique. And this creates additional problems:

This maybe work for your local system. In environments where everything 
is Gentoo and everyone knows Gentoo. But in today's world you are using 
configuration management tools like Ansible, Puppet, Saltstack, Chef...

People who are not necessarily familiar with every implementation detail 
must be able to write configurations (recipes) and the used tool is 
supposed to take care of the differences. In the end, in the ideal 
world, you are just looking at your code describing a state the system 
should have.

But this doesn't work if you make Gentoo so special that you will break 
most tools, will require adjustments or special Gentoo support just for 
stuff Gentoo is doing differently and like everyone else.

Don't get me wrong here: Yes, these tools already have to implement USE 
flags for example which are unique for Gentoo. But stuff like user 
management isn't or should *not*.

When you will get LPIC certification one can expect that you have some 
basic knowledge in Linux stuff allowing you to do common tasks on all 
different Linux systems. Now there comes Gentoo where you aren't allowed 
to use standard Linux tools like 'usermod' when deploying another 
service if you don't want to risk that your service will go down when 
following best practice and do regular world upgrades. Really?


3) More important, the idea of forking acct-* packages whenever you need 
to make modifications don't scale. Like I already outlined in February 
2020, you cannot create overlays for each different user configuration:

I.e. using memcached/redis: You grant permission to socket via group. So 
you put other services belonging to that application you are deploying 
into your user running the key value store. Do you really expect that 
one would create multiple overlays per application using one of these 
services? How would you maintain hundreds of overlays? How would you 
keep track that each box will use the correct overlay to get the 
specific customized acct-* package? How do you deal with scenarios where 
you don't just deploy single instances?

Again, I understand the acct-* fork idea. But I think we have to admit 
that this will only work for the local system or small environments.

For any professional environment this won't work nor scale.


4) Yet we have to talk about the idea in general that it is really not a 
good idea to automatically make changes to the user if you run the risk 
of overwriting changes explicitly made by the system administrator.

It's one thing that multiple local users will get removed from portage 
group when you remerge acct-user/portage, but if you kill services 
because package maintainers are pushing their vision of how to run the 
package, it's not.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

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

[Michael Orlitzky]

On 1/4/21 9:46 AM, Thomas Deutschmann wrote:
> 
>> 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.
> 
> He is obviously looking for a way to allow maintainers to change users
> afterwards. But if we tell people, "If you need customization, fork the
> user/group ebuild in your overlay" we will disconnect these users from
> future changes.

There's pretty much no reason to change a user's settings unless you've 
completely fucked them up the first time around. This is precisely why 
the original GLEP had mailing list reviews.

If a package depends on a user having e.g. a specific home directory so 
that upgrading the package requires a corresponding revision bump of the 
user, then the package is broken. I tried really hard to document this, 
and to enforce it back when we had mailing list reviews. It's all in the 
devmanual now.


> ...
> When you will get LPIC certification one can expect that you have some
> basic knowledge in Linux stuff allowing you to do common tasks on all
> different Linux systems. Now there comes Gentoo where you aren't allowed
> to use standard Linux tools like 'usermod' when deploying another
> service if you don't want to risk that your service will go down when
> following best practice and do regular world upgrades. Really?

You also can't use the standard linux tools to edit scripts in /usr/bin 
without your changes being overwritten. This is no different... some 
things need to belong to the package manager if you want package 
management to work.


> 3) More important, the idea of forking acct-* packages whenever you need
> to make modifications don't scale. Like I already outlined in February
> 2020, you cannot create overlays for each different user configuration:
> 
> I.e. using memcached/redis: You grant permission to socket via group. So
> you put other services belonging to that application you are deploying
> into your user running the key value store. Do you really expect that
> one would create multiple overlays per application using one of these
> services? How would you maintain hundreds of overlays? How would you
> keep track that each box will use the correct overlay to get the
> specific customized acct-* package? How do you deal with scenarios where
> you don't just deploy single instances?

This is literally the example I gave. Our acct-user ebuilds can be added 
to additional groups based on USE flags. Every server uses the same 
overlay/ebuilds, but different machines get different package.use files, 
pushed out by the configuration management tool.

I understand that creating an overlay with acct-user overrides will not 
be for everyone, so I have no problem with adding an escape hatch. I do 
think it should be off by default though, and that missing future 
::gentoo changes will not be a problem unless some other error has been 
committed first.

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

[David Seifert]

On Mon, 2021-01-04 at 10:24 -0500, Michael Orlitzky wrote:
> I understand that creating an overlay with acct-user overrides will
> not 
> be for everyone, so I have no problem with adding an escape hatch. I
> do 
> think it should be off by default though, and that missing future 
> ::gentoo changes will not be a problem unless some other error has
> been 
> committed first.

This is what we agree on. We need an escape hatch, and it needs to be
off by default. Any sysadmin overriding it gets to keep the pieces, but
they need to have that option.

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

[Mike Gilbert]

On Mon, Jan 4, 2021 at 4:23 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Mon, 2021-01-04 at 02:35 +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).
>
> Not modifying an existing user is a horrible default that has already
> bricked one system (by removing /dev/null).  So, over my dead commit
> access.

As the eclass maintainer, would you be willing to merge a similar
patch that enables user modifications by default, but provides
sysadmins a way to disable it?

I have a feeling that there will not be a consensus on the default
behavior, and I could see that getting escalated to council. However,
it might be nice to provide people with the option in the meantime.

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

[Michał Górny]

On Mon, 2021-01-04 at 11:10 -0500, Mike Gilbert wrote:
> On Mon, Jan 4, 2021 at 4:23 AM Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > On Mon, 2021-01-04 at 02:35 +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).
> > 
> > Not modifying an existing user is a horrible default that has already
> > bricked one system (by removing /dev/null).  So, over my dead commit
> > access.
> 
> As the eclass maintainer, would you be willing to merge a similar
> patch that enables user modifications by default, but provides
> sysadmins a way to disable it?

Yes, I don't mind an option, as long as it spews a big fat ewarn that
the user loses the right to support.  However, that's still not
the right solution to the immediate problem, and I'm currently working
on a better patch, so I'd prefer if you waited with that to avoid merge
conflicts.


-- 
Best regards,
Michał Górny

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1247 bytes --]

On 2021-01-04 16:55, David Seifert wrote:
> This is what we agree on. We need an escape hatch, and it needs to be
> off by default. Any sysadmin overriding it gets to keep the pieces, but
> they need to have that option.

See Mike's example again.

In last chapter of Gentoo's handbook (Finalization) we recommend user to 
call 'usermod' to put themselves into important groups like wheel or 
portage.

Now guess what's happening? Whenever acct-user/portage will get 
remerged, PM will remove that user from portage group (luckily groups 
like wheel don't have users...).

Do you really want to extend handbook and tell everyone, "OK, as last 
step, please create an overlay and fork acct-user/portage...". In case 
the answer will be yes, we now have successfully killed the idea of 
allowing maintainers to fix a user/group if this will ever be necessary 
which will add some kind of slap stick to the whole idea.

That's why I am saying that we don't just need an opt-out option, that's 
why I am argue that all this stuff has to be opt-in by default. It's 
something special and unique in Gentoo.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 395 bytes --]

On 2021-01-04 17:14, Michał Górny wrote:
> as long as it spews a big fat ewarn that the user loses the right to
> support.

Could you please elaborate this a little bit more? I cannot agree with 
the way I understand this at the moment but I might miss your point.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Michał Górny]

On Mon, 2021-01-04 at 17:18 +0100, Thomas Deutschmann wrote:
> On 2021-01-04 16:55, David Seifert wrote:
> > This is what we agree on. We need an escape hatch, and it needs to be
> > off by default. Any sysadmin overriding it gets to keep the pieces, but
> > they need to have that option.
> 
> See Mike's example again.
> 
> In last chapter of Gentoo's handbook (Finalization) we recommend user to 
> call 'usermod' to put themselves into important groups like wheel or 
> portage.
> 
> Now guess what's happening? Whenever acct-user/portage will get 
> remerged, PM will remove that user from portage group (luckily groups 
> like wheel don't have users...).

It must be a bug in your version of the eclass.  I've just reemerged
acct-group/wheel and to *my great surprise* I'm still there.  How
unexpected!


-- 
Best regards,
Michał Górny

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 506 bytes --]

On 2021-01-04 17:28, Michał Górny wrote:
> It must be a bug in your version of the eclass.  I've just reemerged
> acct-group/wheel and to*my great surprise*  I'm still there.  How
> unexpected!

That's why I wrote

 >  (luckily groups like wheel don't have users...)

I meant that there is no acct-user/wheel because otherwise this group 
would get cleaned (reset), too.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1601 bytes --]

On 2021-01-04 17:30, Thomas Deutschmann wrote:
> On 2021-01-04 17:28, Michał Górny wrote:
>> It must be a bug in your version of the eclass.  I've just reemerged
>> acct-group/wheel and to*my great surprise*  I'm still there.  How
>> unexpected!
> 
> That's why I wrote
> 
>  >  (luckily groups like wheel don't have users...)
> 
> I meant that there is no acct-user/wheel because otherwise this group 
> would get cleaned (reset), too.

Best example is portage. Follow handbook. Add your user to portage's group:

 > usermod -aG <your user> portage

Now re-emerge acct-user/portage...

> # usermod -aG thomas portage
> # id portage
> uid=250(portage) gid=250(portage) groups=250(portage),1000(thomas)
> # emerge -a1 acct-user/portage
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R    ] acct-user/portage-0::gentoo  0 KiB
> 
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
> 
> Would you like to merge these packages? [Yes/No] y
>>>> Verifying ebuild manifests
>>>> Running pre-merge checks for acct-user/portage-0
>>>> Emerging (1 of 1) acct-user/portage-0::gentoo
>>>> Installing (1 of 1) acct-user/portage-0::gentoo
>>>> Jobs: 1 of 1 complete
>>>> Auto-cleaning packages...
> 
>>>> No outdated packages were found on your system.
> 
>  * GNU info directory index is up-to-date.
> # id portage
> uid=250(portage) gid=250(portage) groups=250(portage)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Michał Górny]

On Mon, 2021-01-04 at 17:34 +0100, Thomas Deutschmann wrote:
> On 2021-01-04 17:30, Thomas Deutschmann wrote:
> > On 2021-01-04 17:28, Michał Górny wrote:
> > > It must be a bug in your version of the eclass.  I've just reemerged
> > > acct-group/wheel and to*my great surprise*  I'm still there.  How
> > > unexpected!
> > 
> > That's why I wrote
> > 
> >  >  (luckily groups like wheel don't have users...)
> > 
> > I meant that there is no acct-user/wheel because otherwise this group 
> > would get cleaned (reset), too.
> 
> Best example is portage. Follow handbook. Add your user to portage's group:
> 
>  > usermod -aG <your user> portage

You've actually added 'portage' to group 'thomas'.


-- 
Best regards,
Michał Górny

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

[James Cloos]

>>>>> "RHJ" == Robin H Johnson <robbat2@gentoo.org> writes:

RHJ> The best I can come up with at the moment, is that any packaging should
RHJ> detect if there are user modifications, and provide control to users
RHJ> based on that fact.

Exactly.  Akin to etc-update.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 457 bytes --]

On 2021-01-04 17:38, Michał Górny wrote:
> You've actually added 'portage' to group 'thomas'.

Yes, I know that.

Well, I understand why this might be confusing for you. Like I was using 
portage as example for the described example when you give another 
service access to a socket like shown in my memcached/redis example.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Mike Gilbert]

On Mon, Jan 4, 2021 at 11:34 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2021-01-04 17:30, Thomas Deutschmann wrote:
> > On 2021-01-04 17:28, Michał Górny wrote:
> >> It must be a bug in your version of the eclass.  I've just reemerged
> >> acct-group/wheel and to*my great surprise*  I'm still there.  How
> >> unexpected!
> >
> > That's why I wrote
> >
> >  >  (luckily groups like wheel don't have users...)
> >
> > I meant that there is no acct-user/wheel because otherwise this group
> > would get cleaned (reset), too.
>
> Best example is portage. Follow handbook. Add your user to portage's group:
>
>  > usermod -aG <your user> portage

I don't see any mention of usermod in the handbook, so I'm not sure
where this came from.

As mgorny pointed out, you are invoking usermod incorrectly. You want
this instead:

usermod -aG portage <your user>

Don't use "id" to list group members. That lists groups of which a
user is a member. Use getent instead:

getent group portage

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

[Michał Górny]

On Mon, 2021-01-04 at 17:50 +0100, Thomas Deutschmann wrote:
> On 2021-01-04 17:38, Michał Górny wrote:
> > You've actually added 'portage' to group 'thomas'.
> 
> Yes, I know that.
> 
> Well, I understand why this might be confusing for you. Like I was using 
> portage as example for the described example when you give another 
> service access to a socket like shown in my memcached/redis example.
> 
> 

This is confusing to me (as is probably to everybody else) because your
text is saying the exact opposite.

| Add your user to portage's group [...]

You're doing the exact opposite.

Maybe it's time to admit that you've made a mistake, and you've made
the same mistake the second time in a row, and although it was proven
wrong before you still keep trying to support your arguments with this
mistake.

-- 
Best regards,
Michał Górny

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

[Mike Gilbert]

On Mon, Jan 4, 2021 at 11:50 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2021-01-04 17:38, Michał Górny wrote:
> > You've actually added 'portage' to group 'thomas'.
>
> Yes, I know that.
>
> Well, I understand why this might be confusing for you. Like I was using
> portage as example for the described example when you give another
> service access to a socket like shown in my memcached/redis example.

That's a really weird example, but if that was your intent please
disregard my last message.

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

[Michael Orlitzky]

On 1/4/21 11:45 AM, James Cloos wrote:
>>>>>> "RHJ" == Robin H Johnson <robbat2@gentoo.org> writes:
> 
> RHJ> The best I can come up with at the moment, is that any packaging should
> RHJ> detect if there are user modifications, and provide control to users
> RHJ> based on that fact.
> 
> Exactly.  Akin to etc-update.
> 

We could implement this with something like an /etc/users.d directory 
that would be populated with entries by either the admin or package 
manager with CONFIG_PROTECT enabled. Then the system database would be 
updated by running something like "users-update" (cf. env-update). The 
essential problem that we need to work around is that e.g. /etc/passwd 
is "owned" by multiple system packages.

I think this would accomplish what you and Robin are talking about, but 
it wouldn't solve whissi's problem since it's still a Gentoo-specific 
solution.

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

[Michał Górny]

On Mon, 2021-01-04 at 13:07 -0500, Michael Orlitzky wrote:
> On 1/4/21 11:45 AM, James Cloos wrote:
> > > > > > > "RHJ" == Robin H Johnson <robbat2@gentoo.org> writes:
> > 
> > RHJ> The best I can come up with at the moment, is that any packaging should
> > RHJ> detect if there are user modifications, and provide control to users
> > RHJ> based on that fact.
> > 
> > Exactly.  Akin to etc-update.
> > 
> 
> We could implement this with something like an /etc/users.d directory 
> that would be populated with entries by either the admin or package 
> manager with CONFIG_PROTECT enabled. Then the system database would be 
> updated by running something like "users-update" (cf. env-update). The 
> essential problem that we need to work around is that e.g. /etc/passwd 
> is "owned" by multiple system packages.

Most importantly, it doesn't resolve the core issue of 'we need to
update home before merging reverse dependencies'.

-- 
Best regards,
Michał Górny

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 2005 bytes --]

Hi,

On 2021-01-04 19:07, Michael Orlitzky wrote:
> We could implement this with something like an /etc/users.d directory 
> that would be populated with entries by either the admin or package 
> manager with CONFIG_PROTECT enabled. Then the system database would be 
> updated by running something like "users-update" (cf. env-update). The 
> essential problem that we need to work around is that e.g. /etc/passwd 
> is "owned" by multiple system packages.
> 
> I think this would accomplish what you and Robin are talking about, but 
> it wouldn't solve whissi's problem since it's still a Gentoo-specific 
> solution.

If you really want to spend so much time on this, feel free to implement 
something like this. From my point of view this is wasted time. I really 
have no words for anyone believing that there must be a way to deal with 
user config. This is a no go for me and most people in my bubble. Once 
you have created something, it's user data. If you want to make changes, 
tell the user about it but never ever mess with user configs. History is 
full of examples when messing with user configs caused real harm.

For example there is a reason why we don't edit /etc files. Instead have 
CONFIG_PROTECT and are only providing helpers to update config.

Do I really need to explain what can go wrong when you suddenly change 
/home? What will happen to your cron jobs for example?

What will happen when you make changes to groups and reboot?

But as said, if you want to spend so much time on this and create a 
complicated solution which will be adding a lot of complexity which I 
think isn't worth it, *I* could live with it. It's the same like dealing 
with CONFIG_PROTECT already.

People like me could just ignore changed users if changes won't go live 
until you run said users-update command or make use of INSTALL_MASK.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Michael Orlitzky]

On 1/4/21 1:23 PM, Thomas Deutschmann wrote:
> 
> People like me could just ignore changed users if changes won't go live
> until you run said users-update command or make use of INSTALL_MASK.
> 

Changes wouldn't go live until you ran etc-update, and *then* users-update.

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 625 bytes --]

On 2021-01-04 19:27, Michael Orlitzky wrote:
>> People like me could just ignore changed users if changes won't go live
>> until you run said users-update command or make use of INSTALL_MASK.
>>
> 
> Changes wouldn't go live until you ran etc-update, and *then* users-update.

This would address my concerns.

But I still wonder if building such a system is worth it... I mean, it 
would be nice to have. Maybe we could build upon such a system to do 
same for (changed) file permissions...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Michael Orlitzky]

On 1/4/21 1:20 PM, Michał Górny wrote:
> 
> Most importantly, it doesn't resolve the core issue of 'we need to
> update home before merging reverse dependencies'.
> 

Quoth the devmanual, "if your package requires a user, you can no longer 
be sure of that user's home directory or its ownership and permissions."
Any package depending on a new revision of an acct-user ebuild to change 
its home directory is broken.

This was the exact problem I was trying to avoid while you made rude 
comments about how I was wasting everyone's time =P

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 598 bytes --]

Hi,

since nobody posted any technical objections, I am going to push the 
proposed patch on Saturday to address the current issue and allow any 
professional Gentoo user relying on usermod/configuration management 
tool to move on.

If someone will spend time on further improvements like implementing the 
idea outlined by Robin or what Michael said about /etc/users.d and 
user-update tool, this is highly appreciated but will probably not 
happen anytime soon.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Mike Gilbert]

On Fri, Jan 8, 2021 at 10:48 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> Hi,
>
> since nobody posted any technical objections, I am going to push the
> proposed patch on Saturday to address the current issue and allow any
> professional Gentoo user relying on usermod/configuration management
> tool to move on.

I strongly object to you pushing this patch as-is. There have been
plenty of non-technical objections, including from the eclass
maintainer.

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1340 bytes --]

On 2021-01-08 17:03, Mike Gilbert wrote:
> I strongly object to you pushing this patch as-is. There have been
> plenty of non-technical objections, including from the eclass
> maintainer.

The eclass maintainer has disqualified himself going into a technical 
debate with saying

> So, over my dead commit access.

in his first posting.


This is a technical mailing list. Currently, acct-* stuff is breaking 
stuff. Nobody has challenged this yet.

Now I proposed a way how to unbreak stuff.

Please tell me why we should keep broken stuff for non-technical reason 
and cause harm for those who are affected?

It's not like we cannot address the other stuff later. It's about 
getting the fix down to users who are currently affected by this. So why 
take hostage when some user(s) ignore the problem for more than a year 
and show that they are not interested in collaboration to find a 
solution for a technical problem they created despite warnings before 
this went live?

Of course, if you are not affected by this problem it is very easy to 
relax and sit back. You have all the time in the world... but when you 
are affected by this at large scale it is not that funny anymore.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 491 bytes --]

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

[Mike Gilbert]

On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
>
> The eclass maintainer has disqualified himself going into a technical
> debate with saying
>
> > So, over my dead commit access.
>
> in his first posting.
>
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> and cause harm for those who are affected?
>
> It's not like we cannot address the other stuff later. It's about
> getting the fix down to users who are currently affected by this. So why
> take hostage when some user(s) ignore the problem for more than a year
> and show that they are not interested in collaboration to find a
> solution for a technical problem they created despite warnings before
> this went live?
>
> Of course, if you are not affected by this problem it is very easy to
> relax and sit back. You have all the time in the world... but when you
> are affected by this at large scale it is not that funny anymore.

Let me put it this way: if you push this without agreement from the
maintainer, QA, or council, you can probably expect a swift revert.

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

[Mike Gilbert]

On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann <whissi@gentoo.org> wrote:
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> and cause harm for those who are affected?

I disagree with your premise: I argue that the eclass is not "broken",
and the code works as designed. You just don't like aspects of its
design.

If you want to change the design, you need buy-in from the maintainer,
or you need to override him.

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

[Michał Górny]

On Fri, 2021-01-08 at 17:29 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
> 
> The eclass maintainer has disqualified himself going into a technical 
> debate with saying
> 
> > So, over my dead commit access.
> 
> in his first posting.

Please remind me, who granted your the power to disqualify maintainers?

> This is a technical mailing list. Currently, acct-* stuff is breaking 
> stuff. Nobody has challenged this yet.

No, it is not.  It is behaving as described.  What really happens is
that you rejected the design, deliberately broke your system and now are
trying to push your design over false arguments.

> It's not like we cannot address the other stuff later. It's about 
> getting the fix down to users who are currently affected by this. So why 
> take hostage when some user(s) ignore the problem for more than a year 
> and show that they are not interested in collaboration to find a 
> solution for a technical problem they created despite warnings before 
> this went live?

Yes, surely me abandoning other work to provide a patch on the same day
proves that I am 'not interested in collaboration to find a solution'.


-- 
Best regards,
Michał Górny

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1514 bytes --]

On 2021-01-08 18:06, Mike Gilbert wrote:
> I disagree with your premise: I argue that the eclass is not "broken",
> and the code works as designed. You just don't like aspects of its
> design.

Several people, not just me... *users*, other devs like robbat2 and 
antarus, all with experience in maintaining multiple systems not just as 
a hobby, have expressed that the current design has a flaw.

I got feedback from other devs representing a large group in Gentoo and 
they all agree on the problem. They haven't spoken up yet because they 
don't care because the way how they use Gentoo is stateless.

So why the hell is it acceptable for a small group (you and mgorny, 
Michael told me already last year that he will be fine with an opt-in 
change and I assume his opinion hasn't changed) to cause problems for 
another group just because you don't want to acknowledge the problem?

Even soap, not sure if he has spoken for himself or as QA lead, has 
acknowledged in this thread that we need a mechanism to disable this 
behavior.

Is it really not possible to solve this technical problem? Do we have to 
escalate and need a vote or something to replace entire GLEP 81 with 
something new just because a group believes there is no flaw and 
everyone else having problems are doing things wrong so this group is 
rejecting any attempts to address the problem?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> Yes, I don't mind an option, as long as it spews a big fat ewarn that
> the user loses the right to support.  However, that's still not
> the right solution to the immediate problem, and I'm currently working
> on a better patch, so I'd prefer if you waited with that to avoid merge
> conflicts.

Could you please share your intended approach?

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Michał Górny]

On Fri, 2021-01-08 at 19:11 +0100, Fabian Groffen wrote:
> On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> > Yes, I don't mind an option, as long as it spews a big fat ewarn that
> > the user loses the right to support.  However, that's still not
> > the right solution to the immediate problem, and I'm currently working
> > on a better patch, so I'd prefer if you waited with that to avoid merge
> > conflicts.
> 
> Could you please share your intended approach?

The one floppym suggested, i.e. the same as sent patch but with
the default staying on the current behavior.

-- 
Best regards,
Michał Górny

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

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 760 bytes --]

On 2021-01-08 19:14, Michał Górny wrote:
> The one floppym suggested, i.e. the same as sent patch but with
> the default staying on the current behavior.

Do I understand correctly? You are willing to accept my patch but with

 > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED

defaulting to a non-zero value to keep current behavior?

This would be an acceptable compromise for me like it would allow users 
like me at least to opt-out. I would still try to convince Gentoo to 
change the default later because I believe this is a bad default but of 
course I would accept any voting results on this implementation detail.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Michał Górny]

On Fri, 2021-01-08 at 19:10 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 18:06, Mike Gilbert wrote:
> > I disagree with your premise: I argue that the eclass is not "broken",
> > and the code works as designed. You just don't like aspects of its
> > design.
> 
> Several people, not just me... *users*, other devs like robbat2 and 
> antarus, all with experience in maintaining multiple systems not just as 
> a hobby, have expressed that the current design has a flaw.

They did.  What you're neglecting to repeat is that they've also
indicated that your proposed design is flawed as well.  You're
conflating 'design A is flawed' into 'design B is better', while they
really said 'both design A and B are flawed'.

> I got feedback from other devs representing a large group in Gentoo and 
> they all agree on the problem. They haven't spoken up yet because they 
> don't care because the way how they use Gentoo is stateless.
> 
> So why the hell is it acceptable for a small group (you and mgorny, 
> Michael told me already last year that he will be fine with an opt-in 
> change and I assume his opinion hasn't changed) to cause problems for 
> another group just because you don't want to acknowledge the problem?

So what's you're basically saying is that there are people who like
behavior A, people who like behavior B and people who don't care. 
Somehow you manage -- without any hard evidence -- to claim that people
who dislike the current behavior are more numerous than the people who
like the current behavior, and also implicitly count people who don't
care towards them (why?).  Even if you managed to prove that (how?), is
this really a popularity contest?

The current behavior has been the default for 1.5 years.  There are
ebuilds that literally depend on it.  If you are going to change that,
then you need to prove that 1) your proposed solution is much better for
the vast majority of Gentoo users (again, how?), and 2) that the benefit
from the change in behavior outweighs its costs.  And given that you've
pretty much admitted that the majority probably 'does not care', then 2)
is not met.

> Even soap, not sure if he has spoken for himself or as QA lead, has 
> acknowledged in this thread that we need a mechanism to disable this 
> behavior.
> 
> Is it really not possible to solve this technical problem? Do we have to 
> escalate and need a vote or something to replace entire GLEP 81 with 
> something new just because a group believes there is no flaw and 
> everyone else having problems are doing things wrong so this group is 
> rejecting any attempts to address the problem?

Again, I don't understand why you continue escalating this.  I have
already indicated that I'm fine with adding an option to disable this,
given that 1) the current behavior remains the default, and 2) people
are given big fat warning that they are now responsible for updating
their users (and ideally 3) the eclass tells user how to update
the user).  I've just asked for the option to override values via
make.conf goes first since that is the preferred solution that doesn't
destroy the foundations of GLEP 81.

floppym has indicated an interest in this, so I've presumed he's going
to submit an updated patch to the ml.


-- 
Best regards,
Michał Górny

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

[Michał Górny]

On Fri, 2021-01-08 at 19:23 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 19:14, Michał Górny wrote:
> > The one floppym suggested, i.e. the same as sent patch but with
> > the default staying on the current behavior.
> 
> Do I understand correctly? You are willing to accept my patch but with
> 
>  > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED
> 
> defaulting to a non-zero value to keep current behavior?
> 
> This would be an acceptable compromise for me like it would allow users 
> like me at least to opt-out. I would still try to convince Gentoo to 
> change the default later because I believe this is a bad default but of 
> course I would accept any voting results on this implementation detail.

In principle, yes.  However, when such a patch is sent I may have more
requests.  For a start, shorter variable name, say, ACCT_USER_NO_MODIFY
or ACCT_USER_NO_UPDATE.

-- 
Best regards,
Michał Górny

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

[Mike Gilbert]

On Fri, Jan 8, 2021 at 1:31 PM Michał Górny <mgorny@gentoo.org> wrote:
> Again, I don't understand why you continue escalating this.  I have
> already indicated that I'm fine with adding an option to disable this,
> given that 1) the current behavior remains the default, and 2) people
> are given big fat warning that they are now responsible for updating
> their users (and ideally 3) the eclass tells user how to update
> the user).  I've just asked for the option to override values via
> make.conf goes first since that is the preferred solution that doesn't
> destroy the foundations of GLEP 81.
>
> floppym has indicated an interest in this, so I've presumed he's going
> to submit an updated patch to the ml.

Sorry, I didn't mean to give that impression. I do not have any plans
to submit patches myself. I asked if you would accept a similar patch
to clarify your position for others (including Whissi) who may want to
contribute.