[gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Michał Górny]

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

Hi,

Here's a reiteration (or well, rewrite) of mjo's earlier work [1].  I've
made it into more GLEP-ish form, removed inline code samples which
belong in implementation part and did some changes.

The main change from the earlier proposal is that we are extremely
careful not to break stuff.  Packages only create users/groups if they
don't exist, they do not modify existing accounts.  Users and groups are
not removed at all.  The text included below.


[1] https://wiki.gentoo.org/wiki/User:Mjo/GLEP:User_packages

---
GLEP: 9999
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-05-29
Post-History: 
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.

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

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 ``user`` category.  Each user package
defines the properties of the particular user, and should be named after
the user it creates.  It must depend at build and run time on the groups
user belongs to.

Group packages are placed in ``group`` category.  Each group package
defines the properties of the particular group, and should 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 can be used 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 time, a run time dependency (``RDEPEND``) must be
used.  If the user is only needed after the package is installed,
``PDEPEND`` 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.

Normally, the packages should not modify existing users, to preserve
local modifications.  If such a modification is necessary, the package
should verify the existing values of changed properties, and update
them only if they match the previous value.

The package must not remove users/groups.  Any cleanup actions must
be done with explicit user approval, and therefore should be addressed
by separate tooling.


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.


User/group name/identifier collision detection
----------------------------------------------

The user/group packages can install additional files in subdirectories
of ``/var/lib`` indicating their respective names and identifiers.
This ensures that if two packages ever happen to collide, the package
manager's collision detection mechanism will trigger.


Rationale
=========

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, and provides for detecting collisions.
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.


Category names
--------------

The original proposal used ``sys-user`` and ``sys-group`` as category
names.  This was changed in order to avoid mixing them with regular
packages in ``sys-*`` categories.

The new names intentionally are single component to distinguish them
from regular packages.


Naming rules
------------

It has been pointed out that the package naming rules are more
restrictive than user/group naming rules.  This is why the proposal
allows for package names to be different from user/group names.
However, this is strongly discouraged and should only be used when
really necessary.


User/group updates
------------------

If sysadmin needs to change the properties (e.g. home directory) of some
user/group, the obvious course of action is to modify the system
databases directly.  The GLEP aims to respect that and disallow altering
existing user/groups unconditionally.  If any updates need to be done,
the packages need to verify previous values first.


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

TODO


References
==========

.. [#GLEP27] GLEP 27: Portage Management of UIDs/GIDs
   (https://www.gentoo.org/glep/glep-0027.html)


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/.
-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Ulrich Mueller]

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

>>>>> On Wed, 29 May 2019, Michał Górny wrote:

> User/group name/identifier collision detection
> ----------------------------------------------

> The user/group packages can install additional files in subdirectories
> of ``/var/lib`` indicating their respective names and identifiers.
> This ensures that if two packages ever happen to collide, the package
> manager's collision detection mechanism will trigger.

I wonder why that would be needed. It won't catch collisions with users
created by the system administrator. Collisions between packages could
certainly be prevented without littering the file system, e.g., by
scanning ebuilds in that category (by repoman, or CI)?

> http://creativecommons.org/licenses/by-sa/3.0/.

s/http/&s/

Ulrich

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

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Jaco Kroon]

Hi Michal,

This sounds sensible and is an interesting approach.  I kinda like it.

There is only one technical comment I have based on the earlier 
discussion, not addressed.

What if users needs to be created into a centralized UID/GID system to 
be pulled in via nss?

So calling system tools by default is fine, but what if the sysadmin 
would prefer to have users and groups pushed into ldap? Can we at least 
accomodate a hook mechanism to allow system administrators not relying 
on local users to deal with this?

My personal rule of thumb is that system users are (and should be) 
local.  But there are definite use cases where shared "system uids" are 
a definite legitimate requirement.

The one complaint I do have is repo bloat.

Further comments below.

Kind Regards,
Jaco

On 2019/05/29 09:28, Michał Górny wrote:
> 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.
>
> 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.

This looks good.  I'd add "6.  Allow for centralized management of users 
and/or groups" (in order to cover management via for example ldap).

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

I would recommend that this be handled via an eclass that deals with the 
technicalities.  The package then does something like:

inherit userpackage

USER_NAME=mail
USER_UID=8
USER_PRIMARY_GROUP=mail
USER_FORCE_UID=yes

DEPEND=group/mail
RDEPEND=group/mail

And that ends up being the whole package.  Similar for groups. Even the 
R?DEPEND can probably go into the eclass.

The eclass can then potentially support external hooks or something to 
accomodate 6. above.

>
> User/group name/identifier collision detection
> ----------------------------------------------
>
> The user/group packages can install additional files in subdirectories
> of ``/var/lib`` indicating their respective names and identifiers.
> This ensures that if two packages ever happen to collide, the package
> manager's collision detection mechanism will trigger.

Ulrich also commented on this.  How about enforcing a mapping from 
$USER_NAME to package name?  (ie, just replace all characters not 
allowed in package naming with _ or -.

Same as Ulrich I struggle to see any use-case where this would be an 
issue, but artificial or not it's probably a good idea to deal with it 
somehow.

> Naming rules
> ------------
>
> It has been pointed out that the package naming rules are more
> restrictive than user/group naming rules.  This is why the proposal
> allows for package names to be different from user/group names.
> However, this is strongly discouraged and should only be used when
> really necessary.

I would personally disallow it and enforce a mapping from username to 
package name.  The question then however is if two names map to the same 
package (which would be confusing to begin with) how to deal with that.

> User/group updates
> ------------------
>
> If sysadmin needs to change the properties (e.g. home directory) of some
> user/group, the obvious course of action is to modify the system
> databases directly.  The GLEP aims to respect that and disallow altering
> existing user/groups unconditionally.  If any updates need to be done,
> the packages need to verify previous values first.

"If any updates need to be done, the package need to verify previous 
values first." conflicts with "disallow altering existing user/groups 
unconditionally".  I'd rephrase as "If any updates need to be done, 
refer those to the system administrator."

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

The type of checks for both this and certain updates contemplated above 
are similar.  And expensive (resources) as you rightly say. I would 
provide the tools to perform these checks but in the ebuild I'd rather 
the checks be done asap (pkg_pretend?).  If we can fail there and 
stating what the admin should do to rectify the issue that would be the 
best solution in my personal opinion.  Ie, from the package manager I'd 
state how, but not actually action these changes.

I would suggest the GLEP restrict the scope of responsibility in this 
respect.  I would recommend ensuring that the account is locked at last.

Would repoman be able to validate unique UID and GID assignments for 
these user/ and group/ packages and enforce use of an eclass for these 
packages?

Kind Regards,
Jaco

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Michał Górny]

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

On Wed, 2019-05-29 at 10:01 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 29 May 2019, Michał Górny wrote:
> > User/group name/identifier collision detection
> > ----------------------------------------------
> > The user/group packages can install additional files in subdirectories
> > of ``/var/lib`` indicating their respective names and identifiers.
> > This ensures that if two packages ever happen to collide, the package
> > manager's collision detection mechanism will trigger.
> 
> I wonder why that would be needed. It won't catch collisions with users
> created by the system administrator. Collisions between packages could
> certainly be prevented without littering the file system, e.g., by
> scanning ebuilds in that category (by repoman, or CI)?

To be honest, I had mixed feelings about this.  I guess I can remove it,
and expect that we'll CI it properly before we phase out the old method.

> > http://creativecommons.org/licenses/by-sa/3.0/.
> 
> s/http/&s/
> 

Sounds like vim templates need to be updated.


-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Michał Górny]

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

On Wed, 2019-05-29 at 11:50 +0200, Jaco Kroon wrote:
> Hi Michal,
> 
> This sounds sensible and is an interesting approach.  I kinda like it.
> 
> There is only one technical comment I have based on the earlier 
> discussion, not addressed.
> 
> What if users needs to be created into a centralized UID/GID system to 
> be pulled in via nss?
> 
> So calling system tools by default is fine, but what if the sysadmin 
> would prefer to have users and groups pushed into ldap? Can we at least 
> accomodate a hook mechanism to allow system administrators not relying 
> on local users to deal with this?

We kinda have hooks already.  Just drop your 'useradd' etc. replacements
into /usr/local/bin, and tadaam!  KISS all the way.

> My personal rule of thumb is that system users are (and should be) 
> local.  But there are definite use cases where shared "system uids" are 
> a definite legitimate requirement.
> 
> The one complaint I do have is repo bloat.
> 
> Further comments below.
> 
> Kind Regards,
> Jaco
> 
> On 2019/05/29 09:28, Michał Górny wrote:
> > 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.
> > 
> > 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.
> 
> This looks good.  I'd add "6.  Allow for centralized management of users 
> and/or groups" (in order to cover management via for example ldap).

I thought this is implied by other points but I guess saying it
explicitly doesn't hurt.

> 
> > 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.
> 
> I would recommend that this be handled via an eclass that deals with the 
> technicalities.  The package then does something like:

This is the plan.  There is already an old version in mjo's overlay,
and I'm planning to put a new one today for review.

> 
> inherit userpackage
> 
> USER_NAME=mail
> USER_UID=8
> USER_PRIMARY_GROUP=mail
> USER_FORCE_UID=yes
> 
> DEPEND=group/mail
> RDEPEND=group/mail
> 
> And that ends up being the whole package.  Similar for groups. Even the 
> R?DEPEND can probably go into the eclass.
> 
> The eclass can then potentially support external hooks or something to 
> accomodate 6. above.
> 
> > User/group name/identifier collision detection
> > ----------------------------------------------
> > 
> > The user/group packages can install additional files in subdirectories
> > of ``/var/lib`` indicating their respective names and identifiers.
> > This ensures that if two packages ever happen to collide, the package
> > manager's collision detection mechanism will trigger.
> 
> Ulrich also commented on this.  How about enforcing a mapping from 
> $USER_NAME to package name?  (ie, just replace all characters not 
> allowed in package naming with _ or -.
> 
> Same as Ulrich I struggle to see any use-case where this would be an 
> issue, but artificial or not it's probably a good idea to deal with it 
> somehow.

This is not so simple.  The main concern are names like 'foo-1'.  But I
guess we can leave it out for now, and address it when we actually have
a need for such user/group.

> 
> > Naming rules
> > ------------
> > 
> > It has been pointed out that the package naming rules are more
> > restrictive than user/group naming rules.  This is why the proposal
> > allows for package names to be different from user/group names.
> > However, this is strongly discouraged and should only be used when
> > really necessary.
> 
> I would personally disallow it and enforce a mapping from username to 
> package name.  The question then however is if two names map to the same 
> package (which would be confusing to begin with) how to deal with that.
> 
> > User/group updates
> > ------------------
> > 
> > If sysadmin needs to change the properties (e.g. home directory) of some
> > user/group, the obvious course of action is to modify the system
> > databases directly.  The GLEP aims to respect that and disallow altering
> > existing user/groups unconditionally.  If any updates need to be done,
> > the packages need to verify previous values first.
> 
> "If any updates need to be done, the package need to verify previous 
> values first." conflicts with "disallow altering existing user/groups 
> unconditionally".  I'd rephrase as "If any updates need to be done, 
> refer those to the system administrator."

I suppose the meaning of 'unconditionally' is ambiguous here.

> 
> > 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 intact.  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.
> 
> The type of checks for both this and certain updates contemplated above 
> are similar.  And expensive (resources) as you rightly say. I would 
> provide the tools to perform these checks but in the ebuild I'd rather 
> the checks be done asap (pkg_pretend?).  If we can fail there and 
> stating what the admin should do to rectify the issue that would be the 
> best solution in my personal opinion.  Ie, from the package manager I'd 
> state how, but not actually action these changes.
> 
> I would suggest the GLEP restrict the scope of responsibility in this 
> respect.  I would recommend ensuring that the account is locked at last.

Yes, I've forgotten about this part.  Locking it out is a good idea.

> Would repoman be able to validate unique UID and GID assignments for 
> these user/ and group/ packages and enforce use of an eclass for these 
> packages?
> 

Not in the current design.  PkgCheck should be able to handle this
though.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Robin H. Johnson]

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

On Wed, May 29, 2019 at 12:25:59PM +0200, Michał Górny wrote:
> On Wed, 2019-05-29 at 11:50 +0200, Jaco Kroon wrote:
> > Hi Michal,
> > 
> > This sounds sensible and is an interesting approach.  I kinda like it.
> > 
> > There is only one technical comment I have based on the earlier 
> > discussion, not addressed.
> > 
> > What if users needs to be created into a centralized UID/GID system to 
> > be pulled in via nss?
> > 
> > So calling system tools by default is fine, but what if the sysadmin 
> > would prefer to have users and groups pushed into ldap? Can we at least 
> > accomodate a hook mechanism to allow system administrators not relying 
> > on local users to deal with this?
> We kinda have hooks already.  Just drop your 'useradd' etc. replacements
> into /usr/local/bin, and tadaam!  KISS all the way.
Having written one of those replacements (diradm), I would like a little
more flexibility:
- permit the sysadmin to configure paths to the useradd(etc)
  tools/wrappers to be actually used.
- include a manual mode that just has the package bail out and wait for
  the sysadmin to do it (e.g. they have to actually create the user on
  another host).

> > My personal rule of thumb is that system users are (and should be) 
> > local.  But there are definite use cases where shared "system uids" are 
> > a definite legitimate requirement.
Created in a central system AND mirrored locally is my preference, using
nsscache.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Michael Orlitzky]

On 5/29/19 4:01 AM, Ulrich Mueller wrote:
> 
> I wonder why that would be needed. It won't catch collisions with users
> created by the system administrator.

The reference implementation did its best not to annoy you here.
Ultimately, no, it can't prevent the system administrator from
clobbering a UID that some package needs. But, most packages won't
insist on a fixed UID. If they do, and if the system administrator
created a "compatible" user (one that doesn't conflict with any of your
useradd arguments), then the existing user account would be reused.


> Collisions between packages could
> certainly be prevented without littering the file system, e.g., by
> scanning ebuilds in that category (by repoman, or CI)?
> 

Memory hazy, but I think I ventured down this road for a few reasons:

 * Using file collisions is a PMS behavior that will work everywhere.
 * Parsing bash variables in repoman/CI sucks and doesn't work.
 * We want to be warned about the collision during development, before
   we push to ::gentoo.
 * We should prevent collisions in overlays, too.
 * The UID that actually gets created may not be the one in your
   ebuild, if it wasn't available. The real UID is only known at
   install-time. (This one is important IIRC.)

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Michael Orlitzky]

On 5/29/19 5:50 AM, Jaco Kroon wrote:
>>
>> This GLEP follows the best practice of leaving obsolete user/groups
>> accounts intact.  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.
> 
> The type of checks for both this and certain updates contemplated above 
> are similar.  And expensive (resources) as you rightly say. I would 
> provide the tools to perform these checks but in the ebuild I'd rather 
> the checks be done asap (pkg_pretend?).  If we can fail there and 
> stating what the admin should do to rectify the issue that would be the 
> best solution in my personal opinion.  Ie, from the package manager I'd 
> state how, but not actually action these changes.
> 

My original goal here was to have "emerge -C <user>" actually uninstall
the user. That turns out to be highly unwise, because you need to audit
the system for things owned and used by said user, and to clean them all
up beforehand. That can take forever, and can't be automated.

Plan (b) was to do exactly as you asked: have the uninstall process bail
out, and tell you what to do. That's... also technically infeasible,
because we don't have a way to make an ebuild bail out of an uninstall.
This could change in the future with an EAPI/PMS update, but simply
isn't an option right now.

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Michael Orlitzky]

On 5/29/19 3:28 AM, Michał Górny wrote:
> 
> 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.
> 

This made complete sense when removal of the user package implied
removal of the system user. It's still not a big deal, but this could
delete the empty home directory of a valid (but locked) user account.

I don't feel strongly either way, just pointing it out.

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Michał Górny]

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

On Wed, 2019-05-29 at 09:28 +0200, Michał Górny wrote:
> Hi,
> 
> Here's a reiteration (or well, rewrite) of mjo's earlier work [1].  I've
> made it into more GLEP-ish form, removed inline code samples which
> belong in implementation part and did some changes.
> 
> The main change from the earlier proposal is that we are extremely
> careful not to break stuff.  Packages only create users/groups if they
> don't exist, they do not modify existing accounts.  Users and groups are
> not removed at all.  The text included below.
> 
> 
> [1] https://wiki.gentoo.org/wiki/User:Mjo/GLEP:User_packages
> 

FTR, I've placed my initial code in [1].  It's neither complete, nor
final design.  I have to address a number of old bugs for user.eclass
first.

[1] https://github.com/gentoo/gentoo/pull/12129

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages

[Jaco Kroon]

Hi,

On 2019/05/29 18:01, Michael Orlitzky wrote:
> On 5/29/19 5:50 AM, Jaco Kroon wrote:
>>> This GLEP follows the best practice of leaving obsolete user/groups
>>> accounts intact.  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.
>> The type of checks for both this and certain updates contemplated above
>> are similar.  And expensive (resources) as you rightly say. I would
>> provide the tools to perform these checks but in the ebuild I'd rather
>> the checks be done asap (pkg_pretend?).  If we can fail there and
>> stating what the admin should do to rectify the issue that would be the
>> best solution in my personal opinion.  Ie, from the package manager I'd
>> state how, but not actually action these changes.
>>
> My original goal here was to have "emerge -C <user>" actually uninstall
> the user. That turns out to be highly unwise, because you need to audit
> the system for things owned and used by said user, and to clean them all
> up beforehand. That can take forever, and can't be automated.
>
> Plan (b) was to do exactly as you asked: have the uninstall process bail
> out, and tell you what to do. That's... also technically infeasible,
> because we don't have a way to make an ebuild bail out of an uninstall.
> This could change in the future with an EAPI/PMS update, but simply
> isn't an option right now.

I think you misunderstood.  My writing was poor on re-read.

My suggestion is to merely lock the user.  And make sure that the admin 
knows this.  Even locking may need to be configurable but by default I 
would lock.

Further, the tools should be provided outside of the ebuild (baselayout 
perhaps) in order to enable the checks to be completed (ie, confirm no 
files has the user as owner), and then report to the sysadmin how to use 
these tools.

On merge:  Perform the checks before any building starts 
(pkg_pretend/pkg_setup, as per libreoffice example I just looked at).  
Need to recheck again obviously just prior to actually making the 
changes.  Bail early in other words during install.

On unmerge:  Lock user.  Advise sysadmin on how to actually remove the 
user (possibly put it in a database somewhere and check somewhere in 
portage that these users are "linkgering", similar to retained libs that 
gets held because of binaries actually still using it, but never 
automatically removed, just checked if the sysadmin has).  Can't (should 
not) fail.

I hope that clarifies.

Kind Regards,
Jaco