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,

On 2019/05/29 09:28, Michał Górny wrote:

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

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

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



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,

Reply via email to