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

[Jaco Kroon <jaco@uls.co.za>]

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