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

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

[Michał Górny]

Changes in v3:

- Added 'Policy' section.  Notably, it deprecates the old method,
  requires RFC for new users/groups, and makes UID/GID assignment
  explicitly required.

- Removed PDEPEND option in favor of RDEPEND.

- Changed the behavior to explicitly update user/group properties
  on rebuild/upgrade.  This is necessary to handle unlocking accounts
  and generally seems to make more sense.

- Removed obsolete category section from rationale.

--
Best regards,
Michał Górny


Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
 glep-0081.rst | 246 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 246 insertions(+)
 create mode 100644 glep-0081.rst

diff --git a/glep-0081.rst b/glep-0081.rst
new file mode 100644
index 0000000..5bfd048
--- /dev/null
+++ b/glep-0081.rst
@@ -0,0 +1,246 @@
+---
+GLEP: 81
+Title: User and group management via dedicated packages
+Author: Michał Górny <mgorny@gentoo.org>,
+        Michael Orlitzky <mjo@gentoo.org>
+Type: Standards Track
+Status: Draft
+Version: 1
+Created: 2019-05-29
+Last-Modified: 2019-06-09
+Post-History: 2019-05-29
+Content-Type: text/x-rst
+Requires: 
+Replaces: 27
+---
+
+Abstract
+========
+
+A new approach for user/group management is proposed.  Regular packages
+in dedicated categories are used to represent and create user and group
+accounts.  Dependencies are used to request users and group from within
+regular packages, and to track their usage.
+
+
+Motivation
+==========
+
+User management in Gentoo is currently ad-hoc.  Users and groups are
+created through calling system tools directly in packages needing them.
+There is no systematic way of tracking which packages need specific
+users or groups, and determining which ones are obsolete.  Coordinating
+properties of users and groups used by multiple packages must be done
+manually by developers.
+
+GLEP 27 originally attempted to address the problem.  Posted in 2004,
+it never had reached the reference implementation state, and became
+obsolete.  [#GLEP27]_
+
+A good system user and group management proposal should address:
+
+1. Tracking usage of users and groups, and determining which ones
+   are obsolete.
+
+2. Sharing users and groups reliably between different packages.
+
+3. Maintaining fixed UIDs/GIDs that are consistent between different
+   systems.
+
+4. Providing local overrides for user/group properties.
+
+5. Ensuring that users and groups are not created unnecessarily
+   at build time.
+
+6. Providing support for centralized account management (e.g. LDAP).
+
+At the same time, the proposal should avoid unnecessary complexity
+to avoid sharing the fate of GLEP 27.  This proposal aims to address
+those points without requiring a new EAPI or any changes in the package
+manager.
+
+
+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.
+
+Before adding a new user and/or group, the developer must send a RFC
+to the ``gentoo-dev`` mailing list.
+
+
+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.
+
+
+Maintaining users/groups
+------------------------
+
+The primary technical function of user and group packages is to create
+the users and groups.  This is done via invoking the respective system
+tools at ``pkg_preinst`` phase.  This is done only if the user/group
+does not exist on the system already.
+
+If the user or group exists already, the package performs necessary
+modifications in order to meet requested properties.  This includes
+updating user's home directory path (but not moving the directory
+itself), shell and/or group membership.  However, UID/GID is not
+modified.
+
+The package must not remove users/groups.  When the account is no longer
+needed, the tooling must ensure that it is locked from access.
+Appropriately, the packages must be able to reenable users when they
+are installed again.
+
+Additional tools may be provided to help users remove groups and users.
+However, such actions need to be explicitly confirmed by the system
+administrator.
+
+
+Home directory ownership
+------------------------
+
+If the user in question uses a regular home directory (i.e. not
+``/dev/null``), the user package should maintain the directory
+via ``keepdir`` command.  This allows for clean removal of the home
+directory if it is no longer needed.  The package manager will also
+apply correct permissions if the directory does not exist yet.
+
+Note that since the user is not created until ``pkg_preinst``,
+the permissions to home directory should not be applied earlier than
+that.
+
+
+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.
+
+
+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.
+
+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.
+
+
+User/group removal
+------------------
+
+The original proposal attempted to remove user/groups automatically
+when the respective package was unmerged.  This required verifying that
+no files are owned by the user/group in question which was both
+expensive in terms of I/O, and fragile.
+
+This GLEP follows the best practice of leaving obsolete user/groups
+accounts while ensuring that they are locked out properly.  This
+guarantees that no files with stale ownership are left 
+e.g. on unmounted filesystems) and that the same UID/GID is not reused
+for another user/group.
+
+
+Backwards Compatibility
+=======================
+
+This GLEP preserves backwards compatibility with the existing method
+of user/group management.  Both methods can coexist as long as necessary
+for the transition period, and the same user/group can be governed
+by both in parallel.
+
+However, some of the advantages will only be reliable once the old
+method is phased out, and only on new installations.  This particularly
+applies to fixed UIDs/GIDs.
+
+
+Reference Implementation
+========================
+
+The reference implementation has been submitted to review on gentoo-dev
+mailing list.  The version at the time of writing is v2.  [#REFIMPL]_
+
+
+References
+==========
+
+.. [#GLEP27] GLEP 27: Portage Management of UIDs/GIDs
+   (https://www.gentoo.org/glep/glep-0027.html)
+
+.. [#REFIMPL] [gentoo-dev] [PATCH v2 0/9] User/group packages
+   (https://archives.gentoo.org/gentoo-dev/message/ccc85af0511f70ee9d3549b89bd8a40b)
+
+
+Copyright
+=========
+This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
+Unported License. To view a copy of this license, visit
+http://creativecommons.org/licenses/by-sa/3.0/.
-- 
2.22.0.rc3

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

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

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

[Michał Górny]

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

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


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

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

[Brian Evans]

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

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



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

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

[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

[Michał Górny]

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

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


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

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

[Andrew Savchenko]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Andrew Savchenko]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[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

[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

[Andrew Savchenko]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[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

[Michał Górny]

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

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


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

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

[Andrey Utkin]

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1014 bytes --]