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

[Michał Górny]

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