[gentoo-dev] Changes made by acct-* ebuilds

[gentoo-dev] Changes made by acct-* ebuilds

[Christopher Head]

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

Hi all,
Yesterday something surprised me. I updated my system and got the acct-{user,group}/lighttpd for the first time. Because lighttpd was running, package installation failed to change the home directory—fine, it printed an error message, I stopped the server, changed the home directory by hand, and started the server back up.

What I didn’t realize was that it also, successfully, removed the lighttpd user from a couple of auxiliary groups I had put it in. It did this without telling me, without printing any messages. I only noticed because I happened to look at syslog and discovered that usermod or gpasswd or whatever it called had logged the changes. Presumably this has broken a service or two (nothing too critical) since now Lighttpd won’t be able to connect to SCGI sockets any more.

Does it make sense for these ebuilds to print out all the changes they make to existing users and groups, so that the sysadmin can see what happened and immediately look into alternative solutions if it breaks something, rather than silently changing things? Maybe this could even be limited to cases where the package is being newly installed (not upgraded) and the user or group already exists, to ease migration from the old world where sysadmins are easily able to do anything we want with our users and groups to the new world where we’re expected to leave them alone as the ebuilds make them, or worst case make out changes in an overlay.

Thoughts?
-- 
Christopher Head

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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Alec Warner]

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

On Wed, Feb 12, 2020 at 10:02 AM Christopher Head <chead@chead.ca> wrote:

> Hi all,
> Yesterday something surprised me. I updated my system and got the
> acct-{user,group}/lighttpd for the first time. Because lighttpd was
> running, package installation failed to change the home directory—fine, it
> printed an error message, I stopped the server, changed the home directory
> by hand, and started the server back up.
>
> What I didn’t realize was that it also, successfully, removed the lighttpd
> user from a couple of auxiliary groups I had put it in. It did this without
> telling me, without printing any messages. I only noticed because I
> happened to look at syslog and discovered that usermod or gpasswd or
> whatever it called had logged the changes. Presumably this has broken a
> service or two (nothing too critical) since now Lighttpd won’t be able to
> connect to SCGI sockets any more.
>

I'm not convinced this behavior is correct, so we may be able to just fix
it.

-A


>
> Does it make sense for these ebuilds to print out all the changes they
> make to existing users and groups, so that the sysadmin can see what
> happened and immediately look into alternative solutions if it breaks
> something, rather than silently changing things? Maybe this could even be
> limited to cases where the package is being newly installed (not upgraded)
> and the user or group already exists, to ease migration from the old world
> where sysadmins are easily able to do anything we want with our users and
> groups to the new world where we’re expected to leave them alone as the
> ebuilds make them, or worst case make out changes in an overlay.
>
> Thoughts?
> --
> Christopher Head

[-- Attachment #2: Type: text/html, Size: 2194 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Wed, 2020-02-12 at 10:02 -0800, Christopher Head wrote:
> Hi all,
> Yesterday something surprised me. I updated my system and got the acct-{user,group}/lighttpd for the first time. Because lighttpd was running, package installation failed to change the home directory—fine, it printed an error message, I stopped the server, changed the home directory by hand, and started the server back up.
> 
> What I didn’t realize was that it also, successfully, removed the lighttpd user from a couple of auxiliary groups I had put it in. It did this without telling me, without printing any messages. I only noticed because I happened to look at syslog and discovered that usermod or gpasswd or whatever it called had logged the changes. Presumably this has broken a service or two (nothing too critical) since now Lighttpd won’t be able to connect to SCGI sockets any more.

I'm pretty sure user.eclass does print whatever changes it is doing.  It
isn't elog-ged though, I admit.  This is probably worth fixing.


--  
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Christopher Head]

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

On Wed, 12 Feb 2020 19:14:45 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> I'm pretty sure user.eclass does print whatever changes it is doing.
> It isn't elog-ged though, I admit.  This is probably worth fixing.

Yes, I meant elog; sorry about the unclear wording. I generally don’t
even see ordinary print output—most of my machines run emerge -jN where
it isn’t shown at all, and even on the serial ones, there’s so much
build output from a few dozen packages that I’m not going to scroll up
looking for specific things which may have been lost from scrollback
anyway.
-- 
Christopher Head

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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Thu, 2020-02-13 at 08:09 -0800, Christopher Head wrote:
> On Wed, 12 Feb 2020 19:14:45 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > I'm pretty sure user.eclass does print whatever changes it is doing.
> > It isn't elog-ged though, I admit.  This is probably worth fixing.
> 
> Yes, I meant elog; sorry about the unclear wording. I generally don’t
> even see ordinary print output—most of my machines run emerge -jN where
> it isn’t shown at all, and even on the serial ones, there’s so much
> build output from a few dozen packages that I’m not going to scroll up
> looking for specific things which may have been lost from scrollback
> anyway.

Just sent a patch to -dev.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Christopher Head]

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

On Thu, 13 Feb 2020 08:09:13 -0800
Christopher Head <chead@chead.ca> wrote:

> On Wed, 12 Feb 2020 19:14:45 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > I'm pretty sure user.eclass does print whatever changes it is doing.
> > It isn't elog-ged though, I admit.  This is probably worth fixing.  

So, I didn’t intend to provoke a massive debate here—personally I
somewhat prefer users being modified by new versions of the user
ebuilds so that I get security fixes as time goes by to fix e.g. users
being in groups they shouldn’t be, but it’s not a huge deal to me.

elogging when the eclass makes changes, though: Michał, do you want me
to file a bug at bugs.gentoo.org for that? Or is it trivial enough you
prefer to just do it straight away and not bother?
-- 
Christopher Head

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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Sat, 2020-02-15 at 22:35 -0800, Christopher Head wrote:
> On Thu, 13 Feb 2020 08:09:13 -0800
> Christopher Head <chead@chead.ca> wrote:
> 
> > On Wed, 12 Feb 2020 19:14:45 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > I'm pretty sure user.eclass does print whatever changes it is doing.
> > > It isn't elog-ged though, I admit.  This is probably worth fixing.  
> 
> So, I didn’t intend to provoke a massive debate here—personally I
> somewhat prefer users being modified by new versions of the user
> ebuilds so that I get security fixes as time goes by to fix e.g. users
> being in groups they shouldn’t be, but it’s not a huge deal to me.
> 
> elogging when the eclass makes changes, though: Michał, do you want me
> to file a bug at bugs.gentoo.org for that? Or is it trivial enough you
> prefer to just do it straight away and not bother?

I've already sent a patch and it's got no replies, so I guess I'll just
push it today.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Thomas Deutschmann]

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

Hi,

thank you for bringing this to the list.

I have the same experience which is the reason why I haven't migrated
most of my packages yet (which is not a good move because I also didn't
post the problem to the list like I wanted *yet*, I only talked to
people via private mail, chat or at FOSDEM about that and was working on
a proposal I wanted to show next week when I am hopefully healthy again).

In short: It was a very bad decision that acct-* stuff is *changing*
existing stuff. This must be turned of *by default*. Maybe provide a
setting a user can put into make.conf to opt into current, still new,
behavior but by default, a package should never ever make changes to
*existing* user (unless it knows for sure it was the only source
creating that user and nothing was changed since creation which isn't
easy to track).

My example is a little bit different:

Please think about all the systems which are managed using some kind
configuration management tool (Puppet, Ansible, Salt, Chef...). It's
really common and there's is nothing wrong to make use of usermod for
example to alter users. All of the tools I mentioned have 'templates'
(=ready to use scripts to set up common software) which will make use of
things like usermod. The problem: You never expect that something in the
OS will get rid of your changes and will revert to something the package
manager believes should be the default.

In environments where you only have to deal with Gentoo, we maybe have
created something *new* which allows for new possibilities, see
https://wiki.gentoo.org/wiki/OpenDKIM#The_new_way

However, this is very bad: Configuration management tools are common
these days. While we also have systemd which helps at least to provide
some kind of interface allowing user to set timezone, time
sychonization, hostname and other general settings the same way across
different distribution, configuration management tools are also an
abstraction layer: You write 'recipes' or 'playbooks', describe 'states'
in a general language and the used cfm tool will know all the
implementation details. So in the end it doesn't matter if you apply
your configuration against Debian, Fedora, RHEL or Gentoo -- the system
you run your code against should be in the described state after all.
That's at least the idea ;-)

Thanks to the new way how we manage user in Gentoo that's no longer the
case: Suddenly you cannot use basic tools like usermod to make changes
to users anymore because you cannot be sure that these settings won't be
reverted.

Also, the idea to create *packages* to represent user configuration
doesn't scale. I already outlined that issue in [1]. Simple example:

You have two services (SerivceA and ServiceB) both using the same
package (say www-servers/nginx). We are talking about something like
'real application server'. While you can overwrite user/group via ebuild
once, you can't do it multiple times for *different* roles. Especially
when you have to deal with some kind of 'dynamic' stuff (see the
Jenkins' discussion). Creating your own acct-* repository *per role*
can't scale (aside the fact that it will be impossible to tell user,
"Yeah... for Gentoo you just cannot use 'append user X to group sudo'
syntax you use in your cfm tool. Instead you have to fork
acct-group/sudo and put user into that ebuild and ensure that this
version is installed). Also, don't forget about servers executing
multiple roles at the same time: It's easier to describe something like
"Make sure user X is in group Y" vs. making sure you have that single
acct-* ebuild creating user X or group Y with everything you ever need
right from the beginning.

tl;dr
We need to change current acct-* eclasses to not change things (i.e. not
changing home, groups...). At least if user/group were created/modified
outside of PM.


See also:
=========
[1]
https://archives.gentoo.org/gentoo-dev/message/05c9b211eb18012d16302194a7bc37e6


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


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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Christopher Head]

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

Hmmmm. Thinking about it more, this feels a lot like “configuration”, and we have a well-established tool for handling sysadmins customizing configuration while packages land new changes: CONFIG_PROTECT. Is that possibly relevant here?
-- 
Christopher Head

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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Thu, 2020-02-13 at 02:32 +0100, Thomas Deutschmann wrote:
> Hi,
> 
> thank you for bringing this to the list.
> 
> I have the same experience which is the reason why I haven't migrated
> most of my packages yet (which is not a good move because I also didn't
> post the problem to the list like I wanted *yet*, I only talked to
> people via private mail, chat or at FOSDEM about that and was working on
> a proposal I wanted to show next week when I am hopefully healthy again).
> 

In other words, instead of bringing the problem up to the person who
created the GLEP and the eclasses and/or community at large, you've been
conspiring behind their back.  Yes, that's really the procommunity
attitude we expect from Council members.  Thanks for showing it again.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Alec Warner]

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

On Wed, Feb 12, 2020 at 9:59 PM Michał Górny <mgorny@gentoo.org> wrote:

> On Thu, 2020-02-13 at 02:32 +0100, Thomas Deutschmann wrote:
> > Hi,
> >
> > thank you for bringing this to the list.
> >
> > I have the same experience which is the reason why I haven't migrated
> > most of my packages yet (which is not a good move because I also didn't
> > post the problem to the list like I wanted *yet*, I only talked to
> > people via private mail, chat or at FOSDEM about that and was working on
> > a proposal I wanted to show next week when I am hopefully healthy again).
> >
>
> In other words, instead of bringing the problem up to the person who
> created the GLEP and the eclasses and/or community at large, you've been
> conspiring behind their back.  Yes, that's really the procommunity
> attitude we expect from Council members.  Thanks for showing it again.
>

This is a bit of a double standard. Either people are 'conspiring behind
your back' or they 'are gathering data for a counterproposal.' There is no
need to paint a negative narrative here.

-A


>
> --
> Best regards,
> Michał Górny
>
>

[-- Attachment #2: Type: text/html, Size: 1690 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Wed, 2020-02-12 at 23:03 -0800, Alec Warner wrote:
> On Wed, Feb 12, 2020 at 9:59 PM Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Thu, 2020-02-13 at 02:32 +0100, Thomas Deutschmann wrote:
> > > Hi,
> > > 
> > > thank you for bringing this to the list.
> > > 
> > > I have the same experience which is the reason why I haven't migrated
> > > most of my packages yet (which is not a good move because I also didn't
> > > post the problem to the list like I wanted *yet*, I only talked to
> > > people via private mail, chat or at FOSDEM about that and was working on
> > > a proposal I wanted to show next week when I am hopefully healthy again).
> > > 
> > 
> > In other words, instead of bringing the problem up to the person who
> > created the GLEP and the eclasses and/or community at large, you've been
> > conspiring behind their back.  Yes, that's really the procommunity
> > attitude we expect from Council members.  Thanks for showing it again.
> > 
> 
> This is a bit of a double standard. Either people are 'conspiring behind
> your back' or they 'are gathering data for a counterproposal.' There is no
> need to paint a negative narrative here.
> 

Yes, I certainly do have a reason to assume positive from someone who
apparently mounts a counterproposal without bothering to consider
the original reasons.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[desultory]

On 02/13/20 03:10, Michał Górny wrote:
> On Wed, 2020-02-12 at 23:03 -0800, Alec Warner wrote:
>> On Wed, Feb 12, 2020 at 9:59 PM Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> On Thu, 2020-02-13 at 02:32 +0100, Thomas Deutschmann wrote:
>>>> Hi,
>>>>
>>>> thank you for bringing this to the list.
>>>>
>>>> I have the same experience which is the reason why I haven't migrated
>>>> most of my packages yet (which is not a good move because I also didn't
>>>> post the problem to the list like I wanted *yet*, I only talked to
>>>> people via private mail, chat or at FOSDEM about that and was working on
>>>> a proposal I wanted to show next week when I am hopefully healthy again).
>>>>
>>>
>>> In other words, instead of bringing the problem up to the person who
>>> created the GLEP and the eclasses and/or community at large, you've been
>>> conspiring behind their back.  Yes, that's really the procommunity
>>> attitude we expect from Council members.  Thanks for showing it again.
>>>
>>
>> This is a bit of a double standard. Either people are 'conspiring behind
>> your back' or they 'are gathering data for a counterproposal.' There is no
>> need to paint a negative narrative here.
>>
> 
> Yes, I certainly do have a reason to assume positive from someone who
> apparently mounts a counterproposal without bothering to consider
> the original reasons.
> 
Given that we have already established that you cannot distinguish
between technical feedback and personal attacks, consider this a
"teachable moment".

You have not been personally attacked in this thread. Someone has posted
commentary critical of something you were involved in. Yes, you expended
significant time and effort in that project but it is the fruits of the
project, not your personal integrity, competence, sanity, nor preference
in ice cream that are being called into question. There is no call for
smearing the other party, just conversing with them, evaluating their
arguments as they evaluate yours and reaching a mutual understanding of
each other's perspectives and issues as they relate to the project at
hand. If they have concerns which the project does not adequately
address in its current form, the implementation can be improved; if
their concerns are adequately addressed by an improved understanding of
the implementation as it exists now, then at the least you will have
discovered where the documentation could be improved.

Note that I am not in any way opining upon the project or implementation
itself as that is immaterial to my point.

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Mike Gilbert]

On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
> In short: It was a very bad decision that acct-* stuff is *changing*
> existing stuff. This must be turned of *by default*. Maybe provide a
> setting a user can put into make.conf to opt into current, still new,
> behavior but by default, a package should never ever make changes to
> *existing* user (unless it knows for sure it was the only source
> creating that user and nothing was changed since creation which isn't
> easy to track).

I think it would make sense to add some eclass variables that would
turn user.eclass functions into no-ops.

I don't agree that this should be happen by default. I suspect the
majority of users do not wish to manage system users/groups
themselves.

[gentoo-dev] Changes made by acct-* ebuilds

[Michael 'veremitz' Everitt]

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

On 13/02/20 16:17, Mike Gilbert wrote:
> On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
>> In short: It was a very bad decision that acct-* stuff is *changing*
>> existing stuff. This must be turned of *by default*. Maybe provide a
>> setting a user can put into make.conf to opt into current, still new,
>> behavior but by default, a package should never ever make changes to
>> *existing* user (unless it knows for sure it was the only source
>> creating that user and nothing was changed since creation which isn't
>> easy to track).
> I think it would make sense to add some eclass variables that would
> turn user.eclass functions into no-ops.
>
> I don't agree that this should be happen by default. I suspect the
> majority of users do not wish to manage system users/groups
> themselves.
>
I would suggest anyone competent enough to build a kernel from scratch
(genkernel users, I'm ignoring you) should be equally at-home managing
system users and groups and associated permissions? Or am I perhaps
overestimating the average Genbuntu users here ... >,<



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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Mike Gilbert]

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

On Thu, Feb 13, 2020 at 6:24 PM Michael 'veremitz' Everitt <
gentoo@veremit.xyz> wrote:

> On 13/02/20 16:17, Mike Gilbert wrote:
> > On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann <whissi@gentoo.org>
> wrote:
> >> In short: It was a very bad decision that acct-* stuff is *changing*
> >> existing stuff. This must be turned of *by default*. Maybe provide a
> >> setting a user can put into make.conf to opt into current, still new,
> >> behavior but by default, a package should never ever make changes to
> >> *existing* user (unless it knows for sure it was the only source
> >> creating that user and nothing was changed since creation which isn't
> >> easy to track).
> > I think it would make sense to add some eclass variables that would
> > turn user.eclass functions into no-ops.
> >
> > I don't agree that this should be happen by default. I suspect the
> > majority of users do not wish to manage system users/groups
> > themselves.
> >
> I would suggest anyone competent enough to build a kernel from scratch
> (genkernel users, I'm ignoring you) should be equally at-home managing
> system users and groups and associated permissions? Or am I perhaps
> overestimating the average Genbuntu users here ... >,<
>
> I said nothing of capability. Most people don’t care to micromanage
> accounts.

[-- Attachment #2: Type: text/html, Size: 1742 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Thomas Deutschmann]

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

On 2020-02-13 17:17, Mike Gilbert wrote:
> I don't agree that this should be happen by default. I suspect the
> majority of users do not wish to manage system users/groups
> themselves.

Follow handbook to get a working system and rebuild entire world. You
will get surprised.

This is really a bad default and it's breaking with existing principles
you can find in most distributions: Don't touch stuff which were changed
by the user.


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


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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Fri, 2020-02-14 at 15:12 +0100, Thomas Deutschmann wrote:
> On 2020-02-13 17:17, Mike Gilbert wrote:
> > I don't agree that this should be happen by default. I suspect the
> > majority of users do not wish to manage system users/groups
> > themselves.
> 
> Follow handbook to get a working system and rebuild entire world. You
> will get surprised.
> 
> This is really a bad default and it's breaking with existing principles
> you can find in most distributions: Don't touch stuff which were changed
> by the user.
> 

So we're apparently dealing with a major breakage where nobody bothered
to report a bug, and it's so urgent that instead of opening a bug you
choose to try to push things your way behind the scenes causing more
users to be hurt by this apparent non-reported bug just so you can have
a better chance of pushing things your way and ignoring the other side
of the resulting breakage.  Makes sense.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Mike Gilbert]

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

On Fri, Feb 14, 2020 at 9:12 AM Thomas Deutschmann <whissi@gentoo.org>
wrote:

> On 2020-02-13 17:17, Mike Gilbert wrote:
> > I don't agree that this should be happen by default. I suspect the
> > majority of users do not wish to manage system users/groups
> > themselves.
>
> Follow handbook to get a working system and rebuild entire world. You
> will get surprised.


Could you just explain please? I’m not inclined to read through the
handbook and rebuild a system to guess what this horrible breakage might
be.

>

[-- Attachment #2: Type: text/html, Size: 988 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Thomas Deutschmann]

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

On 2020-02-14 16:38, Mike Gilbert wrote:
> Could you just explain please? I’m not inclined to read through the
> handbook and rebuild a system to guess what this horrible breakage might
> be.

My point is, that even the handbook tells user to modify groups. I.e.
you should add your user to group X for being able to do Y...

That's OK. That's normal.

But if everything in Gentoo has migrated to acct-* stuff, these changes
will get reverted once the user will re-emerge world including acct-*
package or such a package will get updated for some reason.

This is unexpected. Also, I hope nobody expects that every user using
sudo for example needs to maintain an own acct-*/sudo fork in his/her
overlay in future just because in Gentoo, you cannot use normal Linux
tools like usermod anymore because your changes might get resetted
during some upgrade.

That's what currently might happen with the current implementation which
tries to keep user/group state like described in package. Something you
will only see in Gentoo and no other distribution.


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


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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Fri, 2020-02-14 at 18:09 +0100, Thomas Deutschmann wrote:
> On 2020-02-14 16:38, Mike Gilbert wrote:
> > Could you just explain please? I’m not inclined to read through the
> > handbook and rebuild a system to guess what this horrible breakage might
> > be.
> 
> My point is, that even the handbook tells user to modify groups. I.e.
> you should add your user to group X for being able to do Y...
> 
> That's OK. That's normal.
> 
> But if everything in Gentoo has migrated to acct-* stuff, these changes
> will get reverted once the user will re-emerge world including acct-*
> package or such a package will get updated for some reason.

Why would that happen?  We don't have acct-user/youruser.

> This is unexpected. Also, I hope nobody expects that every user using
> sudo for example needs to maintain an own acct-*/sudo fork in his/her
> overlay in future just because in Gentoo, you cannot use normal Linux
> tools like usermod anymore because your changes might get resetted
> during some upgrade.

Nope, this isn't true.  You're getting things the other way around.

> That's what currently might happen with the current implementation which
> tries to keep user/group state like described in package. Something you
> will only see in Gentoo and no other distribution.

Have you really verified your claims?  Because I really start feeling
like you've voted for the GLEP without reading it, and then started
recruiting people to change it based on guesses, still without reading
it or understanding the implementation.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Thomas Deutschmann]

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

> # usermod -aG thomas postfix
> # id postfix
> uid=207(postfix) gid=207(postfix)
groups=207(postfix),12(mail),1004(thomas)
> # emerge -a1 acct-user/postfix
> [...]
>
> >>> Installing (1 of 1) acct-user/postfix-0::gentoo
>  * checking 0 files for package collisions
> >>> Merging acct-user/postfix-0 to /
> >>> Safely unmerging already-installed instance...
> No package files given... Grabbing a set.
> >>> Regenerating /etc/ld.so.cache...
> >>> Original instance of package unmerged safely.
>  * Updating groups for user 'postfix' ...
>  *  - Groups: postfix,mail
> >>> acct-user/postfix-0 merged.
> >>> Auto-cleaning packages...
>
> [...]
>
> # id postfix
> uid=207(postfix) gid=207(postfix) groups=207(postfix),12(mail)
>


...and if you read that council meeting log and even the mail discussion
before you will read that I always shared concerns about touching
existing user. I was only fine because I was told "We are aware, what
you described won't happen" and I didn't make a secret that I didn't had
the time to fully review and test myself at this time. Now I had the
time to 'play' with this and it looks like all my previous concerns are
true.


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


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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michał Górny]

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

On Fri, 2020-02-14 at 18:42 +0100, Thomas Deutschmann wrote:
> > # usermod -aG thomas postfix
> > # id postfix
> > uid=207(postfix) gid=207(postfix)
> groups=207(postfix),12(mail),1004(thomas)
> > 

And now you're changing the subject.  You've just claimed that *your*
user's group ownership will be overwritten and when challenged you
present the case of *system* user's group ownership being overwritten.

Also, I'd like to point out that adding postfix user to group thomas is
a counter-intuitive example.  Someone could mistakenly assume you're
adding user thomas to group postfix.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Vadim A. Misbakh-Soloviov]

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

> 
> And now you're changing the subject.  You've just claimed that *your*
> user's group ownership will be overwritten and when challenged you
> present the case of *system* user's group ownership being overwritten.

Actually, he showed the rewrite of **system** user (that was modified 
locally).

And, as it already mentioned above, this behaviour violates Gentoo Philosophy 
of not pretending to be smarter than user and don't dictate them a way to go.

So, if the problem is only in the existance of the bug, I can create it 
tomorrow morning.
But it would be great to know that it wont be closed in a minute after with 
"WONTFIX, works as expected".

Also, as already stated, changing the stuff that was modified by user is 
**prohibited**.

P.S. I don't care about your  relations with whissi, but let's back to the 
topic:

[big red letters]
We should **NEVER** ever rewrite any system configuration made by local system 
administrator (call it "user" or whatever). Dixi.
[/big red letters]

Modification of system users and groups are also covered by that user.

So, we, actually don't need any changes to disable acct-* things at all and 
make users to manage all the things by themselves.
We need a change that will prevent any changes over **already existing** user.

I think we should make it in a manner like:
1) when we install acct-pkg for a first time - CONFIG_PROTECT changes, and let 
user to review.
2) when we **reinstall** same package - do **nothing**. Although, I'm not sure 
here:
on the one hand, why should we bother users by merging changes they already 
did before,
on the other hand, it can be useful way to reset to defaults in case if "all 
this stuff is screwed up".
3) when we upgrade acct-package (assuming there was changes) - only allow 
"positive" changes (group additions), but not negative (dropiing groups), and 
anyway CONFIG_PROTECT all the changes.


Well, there is also "kludgy way": does not globally reimplement anything, but:
1)  force CFGPROTECT
2) perform a "light" modification to only perform "positive" modifications 
(see above) on users/groups, but no "negatives".
It will anyway fix the both issues Whissi and OP had. 

-- 
Best regards,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Vadim A. Misbakh-Soloviov]

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

> Modification of system users and groups are also covered by that user.

fix: <...> by that rule.

-- 
Best regards,
mva

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Michael 'veremitz' Everitt]

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

On 14/02/20 19:48, Vadim A. Misbakh-Soloviov wrote:
>> And now you're changing the subject.  You've just claimed that *your*
>> user's group ownership will be overwritten and when challenged you
>> present the case of *system* user's group ownership being overwritten.
> Actually, he showed the rewrite of **system** user (that was modified 
> locally).
>
> And, as it already mentioned above, this behaviour violates Gentoo Philosophy 
> of not pretending to be smarter than user and don't dictate them a way to go.
>
> So, if the problem is only in the existance of the bug, I can create it 
> tomorrow morning.
> But it would be great to know that it wont be closed in a minute after with 
> "WONTFIX, works as expected".
>
> Also, as already stated, changing the stuff that was modified by user is 
> **prohibited**.
>
> P.S. I don't care about your  relations with whissi, but let's back to the 
> topic:
>
> [big red letters]
> We should **NEVER** ever rewrite any system configuration made by local system 
> administrator (call it "user" or whatever). Dixi.
> [/big red letters]
>
> Modification of system users and groups are also covered by that user.
>
> So, we, actually don't need any changes to disable acct-* things at all and 
> make users to manage all the things by themselves.
> We need a change that will prevent any changes over **already existing** user.
>
> I think we should make it in a manner like:
> 1) when we install acct-pkg for a first time - CONFIG_PROTECT changes, and let 
> user to review.
> 2) when we **reinstall** same package - do **nothing**. Although, I'm not sure 
> here:
> on the one hand, why should we bother users by merging changes they already 
> did before,
> on the other hand, it can be useful way to reset to defaults in case if "all 
> this stuff is screwed up".
> 3) when we upgrade acct-package (assuming there was changes) - only allow 
> "positive" changes (group additions), but not negative (dropiing groups), and 
> anyway CONFIG_PROTECT all the changes.
>
>
> Well, there is also "kludgy way": does not globally reimplement anything, but:
> 1)  force CFGPROTECT
> 2) perform a "light" modification to only perform "positive" modifications 
> (see above) on users/groups, but no "negatives".
> It will anyway fix the both issues Whissi and OP had. 
>
There is a filthy hack which works around all this nonsense .. throw all
acct-* packages in a Package.Provided entry, and mask installation of any
other versions ..

*runs and hides*


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

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Mike Gilbert]

On Fri, Feb 14, 2020 at 12:42 PM Thomas Deutschmann <whissi@gentoo.org> wrote:
>
> > # usermod -aG thomas postfix
> > # id postfix
> > uid=207(postfix) gid=207(postfix)
> groups=207(postfix),12(mail),1004(thomas)
> > # emerge -a1 acct-user/postfix
> > [...]
> >
> > >>> Installing (1 of 1) acct-user/postfix-0::gentoo
> >  * checking 0 files for package collisions
> > >>> Merging acct-user/postfix-0 to /
> > >>> Safely unmerging already-installed instance...
> > No package files given... Grabbing a set.
> > >>> Regenerating /etc/ld.so.cache...
> > >>> Original instance of package unmerged safely.
> >  * Updating groups for user 'postfix' ...
> >  *  - Groups: postfix,mail
> > >>> acct-user/postfix-0 merged.
> > >>> Auto-cleaning packages...
> >
> > [...]
> >
> > # id postfix
> > uid=207(postfix) gid=207(postfix) groups=207(postfix),12(mail)
> >

There's a significant difference between changing group membership for
a system user versus a user account that is used interactively.

I don't think the handbook advises people to mess with system accounts.

Re: [gentoo-dev] Changes made by acct-* ebuilds

[Rolf Eike Beer]

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

> There's a significant difference between changing group membership for
> a system user versus a user account that is used interactively.
> 
> I don't think the handbook advises people to mess with system accounts.

From my experience this is quite common for web-stuff and similar things, 
where you suddenly want to be daemon1 in the group of daemon2 so it can read 
it's files.

How about something like an EXTRA_GROUPS env var that one can set via profile? 
That could be set per package, acct-user templates could change that at merge 
time, or if USE=exact-groups is set even complain if the new and old group 
setting does not match. Or the other way round: always fail if the group 
membership of the given user is not exactly what the ebuild states + 
EXTRA_GROUPS, and let the user pass in USE=force-group for that ebuild to fix 
things up.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]