Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-22 Thread Andrey Utkin
On Thu, Jun 20, 2019 at 09:53:46AM -0400, Brian Evans wrote:
> What significance will such numbers have when a daemon uses a new
> UID/GID and really doesn't care what it is?  Why do we have to go
> through the effort of assigning fixed IDs at random?

One reason not mentioned by mjo: this paves the way to resolution of
very old frustrating problem with user/group creation when
cross-compiling entire system from scratch.

See https://bugs.gentoo.org/541406


signature.asc
Description: Digital signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Michał Górny
On Fri, 2019-06-21 at 15:02 +0300, Andrew Savchenko wrote:
> On Fri, 21 Jun 2019 09:18:23 +0200 David Seifert wrote:
> > On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote:
> > > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
> > > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> > > > > On 6/9/2019 7:39 AM, Michał Górny wrote:
> > > > > > +Tracking of user/group usage is done through dependencies.  As
> > > > > > long
> > > > > > +as any installed package depends on a specific user/group
> > > > > > package,
> > > > > > +the respective user/group is assumed to be used.  If no
> > > > > > package
> > > > > > +requiring the specific user/group is left, the package manager
> > > > > > +automatically prunes the package clearly indicating it is no
> > > > > > longer
> > > > > > +used.
> > > > > 
> > > > > You cannot know when a name is "no longer used".  An
> > > > > administrator could
> > > > > have adopted a username for other purposes.
> > > > 
> > > > That's why we don't remove the actual user/group.  However, this is
> > > > a valuable information to the administrator that no package is
> > > > using
> > > > the user/group in question.
> > > 
> > > So how do you propose to clean them up? Or let user systems trash
> > > with unused uids/gids? The GLEP 81 only mensions some possible
> > > tooling for cleanup. Is there an implementation available? I don't
> > > see it within proposed patch sets.
> > > 
> > > This GLEP should not be accepted unless all necessary tools are
> > > available including a cleanup tool.
> > > 
> > > Best regards,
> > > Andrew Savchenko
> > 
> > Strongly disagree:
> > 
> > 1) User systems are already getting trashed. And apparently it's not a
> > critical thing that prevents users from using Gentoo in practice.
> > 2) A cleanup tool at best will only tell you which files you need to
> > check, randomly deleting files with orphaned uids/gids is not a good
> > idea.
> 
> What will happen when some acct-*/* package will be unmerged? Will
> uid/gid record and/or its files be deteleted?
> 

They will be marked as unused, locked from access and left in system
databases.  It's both in the GLEP and in the implementation.  All you
have to do is to read before complaining.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread David Seifert
On Fri, 2019-06-21 at 15:02 +0300, Andrew Savchenko wrote:
> On Fri, 21 Jun 2019 09:18:23 +0200 David Seifert wrote:
> > On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote:
> > > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
> > > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> > > > > On 6/9/2019 7:39 AM, Michał Górny wrote:
> > > > > > +Tracking of user/group usage is done through
> > > > > > dependencies.  As
> > > > > > long
> > > > > > +as any installed package depends on a specific user/group
> > > > > > package,
> > > > > > +the respective user/group is assumed to be used.  If no
> > > > > > package
> > > > > > +requiring the specific user/group is left, the package
> > > > > > manager
> > > > > > +automatically prunes the package clearly indicating it is
> > > > > > no
> > > > > > longer
> > > > > > +used.
> > > > > 
> > > > > You cannot know when a name is "no longer used".  An
> > > > > administrator could
> > > > > have adopted a username for other purposes.
> > > > 
> > > > That's why we don't remove the actual user/group.  However,
> > > > this is
> > > > a valuable information to the administrator that no package is
> > > > using
> > > > the user/group in question.
> > > 
> > > So how do you propose to clean them up? Or let user systems trash
> > > with unused uids/gids? The GLEP 81 only mensions some possible
> > > tooling for cleanup. Is there an implementation available? I
> > > don't
> > > see it within proposed patch sets.
> > > 
> > > This GLEP should not be accepted unless all necessary tools are
> > > available including a cleanup tool.
> > > 
> > > Best regards,
> > > Andrew Savchenko
> > 
> > Strongly disagree:
> > 
> > 1) User systems are already getting trashed. And apparently it's
> > not a
> > critical thing that prevents users from using Gentoo in practice.
> > 2) A cleanup tool at best will only tell you which files you need
> > to
> > check, randomly deleting files with orphaned uids/gids is not a
> > good
> > idea.
> 
> What will happen when some acct-*/* package will be unmerged? Will
> uid/gid record and/or its files be deteleted?
> 
> > 3) This proposal strictly increases the quality of Gentoo. Don't
> > let
> > perfect be the enemy of the good. The fact that the problem isn't
> > solved to 100% doesn't mean that a solution that gets us there 85%
> > should be rejected.
> > 
> > Strongly vote +1 to merge this now.
> > 
> > 
> 
> Best regards,
> Andrew Savchenko

They will remain orphaned on the file system. So again, this is in no
way worse than the status quo, and given that users/groups will be
managed through a package manager, tracking orphaned uids/gids is a lot
better with this proposal.




Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Andrew Savchenko
On Fri, 21 Jun 2019 09:18:23 +0200 David Seifert wrote:
> On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote:
> > On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
> > > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> > > > On 6/9/2019 7:39 AM, Michał Górny wrote:
> > > > > +Tracking of user/group usage is done through dependencies.  As
> > > > > long
> > > > > +as any installed package depends on a specific user/group
> > > > > package,
> > > > > +the respective user/group is assumed to be used.  If no
> > > > > package
> > > > > +requiring the specific user/group is left, the package manager
> > > > > +automatically prunes the package clearly indicating it is no
> > > > > longer
> > > > > +used.
> > > > 
> > > > You cannot know when a name is "no longer used".  An
> > > > administrator could
> > > > have adopted a username for other purposes.
> > > 
> > > That's why we don't remove the actual user/group.  However, this is
> > > a valuable information to the administrator that no package is
> > > using
> > > the user/group in question.
> > 
> > So how do you propose to clean them up? Or let user systems trash
> > with unused uids/gids? The GLEP 81 only mensions some possible
> > tooling for cleanup. Is there an implementation available? I don't
> > see it within proposed patch sets.
> > 
> > This GLEP should not be accepted unless all necessary tools are
> > available including a cleanup tool.
> > 
> > Best regards,
> > Andrew Savchenko
> 
> Strongly disagree:
> 
> 1) User systems are already getting trashed. And apparently it's not a
> critical thing that prevents users from using Gentoo in practice.
> 2) A cleanup tool at best will only tell you which files you need to
> check, randomly deleting files with orphaned uids/gids is not a good
> idea.

What will happen when some acct-*/* package will be unmerged? Will
uid/gid record and/or its files be deteleted?

> 3) This proposal strictly increases the quality of Gentoo. Don't let
> perfect be the enemy of the good. The fact that the problem isn't
> solved to 100% doesn't mean that a solution that gets us there 85%
> should be rejected.
> 
> Strongly vote +1 to merge this now.
> 
> 


Best regards,
Andrew Savchenko


pgpDwJ3IynjJd.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Jaco Kroon

Hi,

On 2019/06/21 07:59, Andrew Savchenko wrote:

On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:

On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:

On 6/9/2019 7:39 AM, Michał Górny wrote:

+Tracking of user/group usage is done through dependencies.  As long
+as any installed package depends on a specific user/group package,
+the respective user/group is assumed to be used.  If no package
+requiring the specific user/group is left, the package manager
+automatically prunes the package clearly indicating it is no longer
+used.

You cannot know when a name is "no longer used".  An administrator could
have adopted a username for other purposes.

That's why we don't remove the actual user/group.  However, this is
a valuable information to the administrator that no package is using
the user/group in question.

So how do you propose to clean them up? Or let user systems trash
with unused uids/gids? The GLEP 81 only mensions some possible
tooling for cleanup. Is there an implementation available? I don't
see it within proposed patch sets.

This GLEP should not be accepted unless all necessary tools are
available including a cleanup tool.


find / -{user,group} ???

For files having ownership at least.

There may well be other reasons why the user is still in use (that I 
can't think of right now), but unfortunately this is what makes this so 
difficult.  I'd propose that some tool be used that provides hooks to 
allow additional checks to be added.


Kind Regards,
Jaco




Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread David Seifert
On Fri, 2019-06-21 at 08:59 +0300, Andrew Savchenko wrote:
> On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
> > On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> > > On 6/9/2019 7:39 AM, Michał Górny wrote:
> > > > +Tracking of user/group usage is done through dependencies.  As
> > > > long
> > > > +as any installed package depends on a specific user/group
> > > > package,
> > > > +the respective user/group is assumed to be used.  If no
> > > > package
> > > > +requiring the specific user/group is left, the package manager
> > > > +automatically prunes the package clearly indicating it is no
> > > > longer
> > > > +used.
> > > 
> > > You cannot know when a name is "no longer used".  An
> > > administrator could
> > > have adopted a username for other purposes.
> > 
> > That's why we don't remove the actual user/group.  However, this is
> > a valuable information to the administrator that no package is
> > using
> > the user/group in question.
> 
> So how do you propose to clean them up? Or let user systems trash
> with unused uids/gids? The GLEP 81 only mensions some possible
> tooling for cleanup. Is there an implementation available? I don't
> see it within proposed patch sets.
> 
> This GLEP should not be accepted unless all necessary tools are
> available including a cleanup tool.
> 
> Best regards,
> Andrew Savchenko

Strongly disagree:

1) User systems are already getting trashed. And apparently it's not a
critical thing that prevents users from using Gentoo in practice.
2) A cleanup tool at best will only tell you which files you need to
check, randomly deleting files with orphaned uids/gids is not a good
idea.
3) This proposal strictly increases the quality of Gentoo. Don't let
perfect be the enemy of the good. The fact that the problem isn't
solved to 100% doesn't mean that a solution that gets us there 85%
should be rejected.

Strongly vote +1 to merge this now.




Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Andrew Savchenko
Hi!

On Thu, 20 Jun 2019 09:53:46 -0400 Brian Evans wrote:
> > +
> > +Before adding a new user and/or group, the developer must send a RFC
> > +to the ``gentoo-dev`` mailing list.
> 
> This paragraph should go away.  It is a complete waste of time.

> > +Requiring mailing list RFC
> > +--
> > +
> > +The policy explicitly requires RFC-es for new users and groups, as they
> > +have global scopes and effects of mistakes while adding them are hard
> > +to fix.  Wider review should decrease the risk of major design mistakes.
> > +
> > +To provide one example, right now we have two different packages
> > +creating ``git`` user and requiring a different home directory for
> > +the user.  As a result, the first package being installed defines
> > +the actual home directory, and both technically can not be installed
> > +at the same time.
> 
> This section should go away.  It is a complete waste of time.

Mail list discussion may make sense only if users or groups and
intended to be shared between different applications (e.g. ftp,
mail, ntp). If user or group are intended to be application
specific, there is no need for such discussions as they will just
hinder development process.

Best regards,
Andrew Savchenko


pgp1O4TymKEO2.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-21 Thread Andrew Savchenko
On Thu, 20 Jun 2019 16:32:56 +0200 Michał Górny wrote:
> On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> > On 6/9/2019 7:39 AM, Michał Górny wrote:
> > > +Tracking of user/group usage is done through dependencies.  As long
> > > +as any installed package depends on a specific user/group package,
> > > +the respective user/group is assumed to be used.  If no package
> > > +requiring the specific user/group is left, the package manager
> > > +automatically prunes the package clearly indicating it is no longer
> > > +used.
> > 
> > You cannot know when a name is "no longer used".  An administrator could
> > have adopted a username for other purposes.
> 
> That's why we don't remove the actual user/group.  However, this is
> a valuable information to the administrator that no package is using
> the user/group in question.

So how do you propose to clean them up? Or let user systems trash
with unused uids/gids? The GLEP 81 only mensions some possible
tooling for cleanup. Is there an implementation available? I don't
see it within proposed patch sets.

This GLEP should not be accepted unless all necessary tools are
available including a cleanup tool.

Best regards,
Andrew Savchenko


pgpDkqP5Gug7l.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-20 Thread Michał Górny
On Thu, 2019-06-20 at 09:53 -0400, Brian Evans wrote:
> On 6/9/2019 7:39 AM, Michał Górny wrote:
> > +Tracking of user/group usage is done through dependencies.  As long
> > +as any installed package depends on a specific user/group package,
> > +the respective user/group is assumed to be used.  If no package
> > +requiring the specific user/group is left, the package manager
> > +automatically prunes the package clearly indicating it is no longer
> > +used.
> 
> You cannot know when a name is "no longer used".  An administrator could
> have adopted a username for other purposes.

That's why we don't remove the actual user/group.  However, this is
a valuable information to the administrator that no package is using
the user/group in question.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-20 Thread Michael Orlitzky
On 6/20/19 9:53 AM, Brian Evans wrote:
>> +
>> +Following the acceptance of this GLEP, all new users and groups must
>> +be created via user/group packages as defined in this GLEP.  The old
>> +method may still be used for existing users/groups, in existing
>> +packages.
>> +
>> +All new users and groups must have unique UIDs/GIDs assigned
>> +by developers.  The developer adding them is responsible for checking
>> +for collisions.
> 
> What significance will such numbers have when a daemon uses a new
> UID/GID and really doesn't care what it is?  Why do we have to go
> through the effort of assigning fixed IDs at random?
> 

People want this. Here's the thread from 2017:

https://archives.gentoo.org/gentoo-dev/message/2355afd4f5b72651e2ff47ea8b10c1fe

Selectively quoting:

  * I might be not following correctly, but due to how filesystems/etc
work it is probably desirable to have consistent UID/GIDs as much as
reasonably possible. -rich0

  * I don't think we need to have stable UIDs/GIDs in the "normal" case
of standalone users with a single Gentoo system at home. The people
who need predictable UIDs/GIDs are the "enterprise" users or the
home users who use things such as NFS. I work for a company that
uses Gentoo, we have a bunch of workarounds to make sure that UIDs
and GIDs are stable. -chutzpah

  * I for one am more than willing to do whatever shell commands
necessary to make all my Gentoo installs agree on UIDs and get
[fixed UID proposal] now, but I realise most people are not.
-A. Wilcox

  * YES! I think after [fixed UIDs] is finalized, it should be part of
the handbook installation as a default, but selectable. -james

  * If the user does not exist then create it. Preferably use a pre-
assigned UID/GID so there is some consistency with most other
Gentoo things out there. -Alan McKinnon

This will make a lot of peoples' lives easier, and is very easy to do.



Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-20 Thread Brian Evans
On 6/9/2019 7:39 AM, Michał Górny wrote:
> +Specification
> +=
> +
> +Policy
> +--
> +
> +Following the acceptance of this GLEP, all new users and groups must
> +be created via user/group packages as defined in this GLEP.  The old
> +method may still be used for existing users/groups, in existing
> +packages.
> +
> +All new users and groups must have unique UIDs/GIDs assigned
> +by developers.  The developer adding them is responsible for checking
> +for collisions.

What significance will such numbers have when a daemon uses a new
UID/GID and really doesn't care what it is?  Why do we have to go
through the effort of assigning fixed IDs at random?

> +
> +Before adding a new user and/or group, the developer must send a RFC
> +to the ``gentoo-dev`` mailing list.

This paragraph should go away.  It is a complete waste of time.


> +
> +
> +Logical structure
> +-
> +
> +In this proposal, system users and groups are represented by regular
> +packages.  Those packages logically represent the ownership of
> +the respective users and group, and technically implement their
> +creation.
> +
> +User packages are placed in ``acct-user`` category.  Each user package
> +defines the properties of the particular user, and must be named after
> +the user it creates.  It must depend at build and run time on the groups
> +the user belongs to.
> +
> +Group packages are placed in ``acct-group`` category.  Each group
> +package defines the properties of the particular group, and must be
> +named after the group it creates.
> +
> +All user and group packages must define preferred fixed UIDs/GIDs,
> +and they must be unique within the repository.  The packages should
> +indicate whether the value needs to be strictly enforced, or whether
> +another UID/GID is acceptable when the user exists already or requested
> +UID/GID is taken.
> +
> +Packages needing a specific user or group use dependencies to pull
> +the required user/group packages.  If the user is needed at build time,
> +a build time dependency (``DEPEND``) must be used.  If the user is
> +needed at install and/or run time, a run time dependency (``RDEPEND``)
> +must be used.

Sounds like extra upgrade dependency time in an already crowded
resolution tree.

> +
> +Rationale
> +=
> +
> +Requiring mailing list RFC
> +--
> +
> +The policy explicitly requires RFC-es for new users and groups, as they
> +have global scopes and effects of mistakes while adding them are hard
> +to fix.  Wider review should decrease the risk of major design mistakes.
> +
> +To provide one example, right now we have two different packages
> +creating ``git`` user and requiring a different home directory for
> +the user.  As a result, the first package being installed defines
> +the actual home directory, and both technically can not be installed
> +at the same time.

This section should go away.  It is a complete waste of time.

> +
> +
> +Satisfied goals
> +---
> +
> +Tracking of user/group usage is done through dependencies.  As long
> +as any installed package depends on a specific user/group package,
> +the respective user/group is assumed to be used.  If no package
> +requiring the specific user/group is left, the package manager
> +automatically prunes the package clearly indicating it is no longer
> +used.

You cannot know when a name is "no longer used".  An administrator could
have adopted a username for other purposes.

> +
> +Each user and group has a single respective package creating it.
> +If multiple packages need it, they depend on the same package.  This
> +ensures that all properties are kept in a single location, and do not
> +need to be synced.
> +
> +Having a single location with all predefined user/group ranges makes it
> +possible to maintain fixed UID/GID definitions.  This GLEP makes
> +allocating them obligatory.  While this isn't enforced for existing
> +users, it provides a way forward for new installations.
> +
> +Local overrides can be trivially implemented via local repository,
> +through overriding the respective user/group ebuilds.  The proposal also
> +respects direct sysadmin modifications.
> +
> +Avoiding unnecessary user/group creation at build time is implemented
> +via correct dependency types.  While this was possible with the status
> +quo, the dependency model should be more natural to developers and cause
> +less mistakes.
> +
> +




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-12 Thread Michał Górny
On Wed, 2019-06-12 at 22:21 -0400, Michael Orlitzky wrote:
> On 6/9/19 7:39 AM, Michał Górny wrote:
> > +
> > +All new users and groups must have unique UIDs/GIDs assigned
> > +by developers.  The developer adding them is responsible for checking
> > +for collisions.
> > 
> > ...
> > 
> > +All user and group packages must define preferred fixed UIDs/GIDs,
> > +and they must be unique within the repository.  The packages should
> > +indicate whether the value needs to be strictly enforced, or whether
> > +another UID/GID is acceptable when the user exists already or requested
> > +UID/GID is taken.
> > +
> 
> Maybe we should loosen this in the case of enforced UIDs. If two
> user-packages truly do require the same fixed UID (for whatever godawful
> reason), then obviously they can't be installed on the same machine, but
> we could otherwise support both in the repository.

I'd rather not permit it up front.  We can revisit this if it ever
becomes really necessary.

> 
> I don't want to encourage people to add such badly-written software to
> the repo, but the alternative is also pretty ugly: if we require the
> UIDs to be unique, and if two packages require the same enforced UID,
> then whoever commits to ::gentoo first will prevent the other guy from
> adding his package later on.

The alternative is to prevent user from installing the second package
without manually fixing his UID/GID table.  This is horrible UX.
I suppose patching one of the packages to use another UID/GID is
probably better.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v3] glep-0081: User and group management via dedicated packages

2019-06-12 Thread Michael Orlitzky
On 6/9/19 7:39 AM, Michał Górny wrote:
> 
> +
> +All new users and groups must have unique UIDs/GIDs assigned
> +by developers.  The developer adding them is responsible for checking
> +for collisions.
> 
> ...
> 
> +All user and group packages must define preferred fixed UIDs/GIDs,
> +and they must be unique within the repository.  The packages should
> +indicate whether the value needs to be strictly enforced, or whether
> +another UID/GID is acceptable when the user exists already or requested
> +UID/GID is taken.
> +

Maybe we should loosen this in the case of enforced UIDs. If two
user-packages truly do require the same fixed UID (for whatever godawful
reason), then obviously they can't be installed on the same machine, but
we could otherwise support both in the repository.

I don't want to encourage people to add such badly-written software to
the repo, but the alternative is also pretty ugly: if we require the
UIDs to be unique, and if two packages require the same enforced UID,
then whoever commits to ::gentoo first will prevent the other guy from
adding his package later on.