Re: [gentoo-dev] Requirements for UID/GID management

[Michał Górny]

On Fri, 27 Jan 2017 12:54:07 -0500
Michael Orlitzky <mjo@g.o> wrote:

> We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but
> never implemented it. I'm wondering what are the explicit requirements
> that we have for user and group management?

I don't think GLEP 27 could be really considered approved if it hasn't
seen any action for 12 years.

> What I'm really wondering is, instead of the proposal in GLEP27, if we
> couldn't simply handle users like any other package. For example,
> net-dns/djbdns needs,
>
>   pkg_preinst() {
>     # The nofiles group is no longer provided by baselayout.
>     # Share it with qmail if possible.
>     enewgroup nofiles 200
>
>     enewuser dnscache -1 -1 -1 nofiles
>     enewuser dnslog -1 -1 -1 nofiles
>     enewuser tinydns -1 -1 -1 nofiles
>   }
>
> Instead of that, why couldn't we have something like,
>
>   (R)DEPEND="sys-user/dnscache
>              sys-user/dnslog
>              sys-user/tinydns"
>
> and then in each of those packages,
>
>   (R)DEPEND="sys-group/nofiles"

At a first glance it seems like a lot of effort for a problem that's
already well-solved on the eclass level. However, it probably makes
sense when you consider users/groups created by multiple packages.

> That satisfies most of the requirements that *I* have for user and group
> management on the system. Compared to the GLEP:
>
>   * EUSERS + EGROUPS: replaced by (R)DEPEND.
>   * Defining Accounts: anyone can add a new package already.
>   * FEATURES=noautoaccts: use package.provided instead.
>   * Local Overrides: use an overlay.
>   * users-update: cleanup can be done with --depclean now.

Err, cleanup is never easy. You shouldn't really remove a user if it
owns any files. I guess you could abuse pkg_prerm() for that but
depclean will be terribly slow then.

> You don't really have to care what UID/GID is assigned, because each
> user/group will only be created once and referenced by name (as $PN). By
> default, we could pick the first available UID in most packages.
> I haven't thought much about the src_install implementation, but it
> couldn't be *that* hard. Maybe install a $uid file to /var/lib/portage
> somewhere to catch UID conflicts, and keep doing what user.eclass is
> doing otherwise.

Let's invent /etc/passwd.d and /etc/group.d ;-P.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>