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
