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