Bug 16142

Summary:	Supporting /usr/lib/passwd
Product:	glibc	Reporter:	Colin <walters>
Component:	libc	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	carlos, cickumqt, drepper.fsp, fweimer, jhrozek
Priority:	P2	Flags:	fweimer: security-
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Colin 2013-11-08 15:33:05 UTC

Historically on Unix, /etc/passwd has been the "default" backend for user data, and this is implemented by glibc's "files" backend.

However, as part of the https://live.gnome.org/OSTree project, I am trying to create a stronger separation between the operating system defaults, and per-machine configuration.

As used by both mainstream package systems like Debian (dpkg) and Red Hat Enterprise Linux (rpm), the way the system works is that post-install scripts run "useradd" or equivalent, which dynamically adds system users to /etc/passwd.

The problem is that this file also contains users added interactively by the system administrator, which means that it requires special merge logic.

If instead glibc supported /usr/lib/passwd, then these package systems (and systems using OSTree) could put system password data there.

The key advantage of this is it's much more clear who "owns" the data.  /usr/lib/passwd is owned by dpkg/rpm, in the same way /usr/bin/bash is.

The driving rationale for me is that OSTree demands very clear semantics for the 3 directories of /etc, /usr, and /var.  It will do an automatic basic 3 way merge for /etc, and this works well for the vast majority of files there on modern systems - /etc/passwd is the major exception.

(This all appies for /etc/group of course too).

Comment 1 Colin 2013-11-08 15:37:45 UTC

Moving on to implementation; at the moment, my OS (gnome-continuous) has a hacked up copy of the glibc "files" backend which just looks up in /usr/lib/passwd, then our default /etc/nsswitch.conf has:

passwd: files altfiles
group: files altfiles

Now what I'd like to move on to here is upstreaming this logic, because my ultimate plan is to have OSTree's logic *underneath* dpkg/rpm, and to do that really, I'd like Debian and Red Hat Enterprise Linux to come capable of this out of the box.

So for upstreaming, what do you think of these options?

1) Change "files" to do this by default
 1a) Unconditionally (though obviously not erroring out if /usr/lib/passwd doesn't exist)
 1b) Behind a build-time --enable-usrlib-passwd option
2) Ship "usrlibfiles" as a separate upstream module
3) Something else?

I personally think 1a) will be fine, but I'm open to discussion.

Comment 2 Carlos O'Donell 2014-04-04 05:52:33 UTC

You'll need to post your patches to libc-alpha with some very very strong rationale for wanting to support /usr/lib/passwd, starting with use cases and why /etc/passwd is currently problematic for your use cases. Please make sure you lead with your examples and use cases to justify /usr/lib/passwd. As it stands right now you haven't provided enough rationale to complicated system administration with another password file.

Please read through the contribution checklist carefully:
https://sourceware.org/glibc/wiki/Contribution%20checklist

If you want some review you can post to libc-help and we can hash out the patch and any style issues before posting a fully baked solution to libc-alpha, but that's up to you.

Comment 3 Colin 2014-04-11 06:08:39 UTC

(In reply to Carlos O'Donell from comment #2)
> You'll need to post your patches to libc-alpha with some very very strong
> rationale for wanting to support /usr/lib/passwd, 

It might be that the right thing is for nss-altfiles to live outside of glibc.  If we choose that path though, one thing I'd like is something like /etc/nsswitch.conf.d or perhaps better, just /usr/lib/nss and where it looks like:

10-files.so
20-nss-altfiles.so
30-sssd.so

etc.  Then the NSS module is loaded and specifies which services it should offer.  (Does anyone ever even want sss for passwd but not group?  I don't think so) 

> starting with use cases

Atomic upgrades.

> and why /etc/passwd is currently problematic for your use cases.

Because it requires a semantic merge.  Don't get me wrong, I *could* choose to hardcode special support for merges on upgrades of /etc/passwd.

RPM and dpkg effectively do this now by calling useradd.

But it's far cleaner I think to have system users in a separate place from human users.

For what it's worth, from looking around, CoreOS is also using /usr/lib/passwd.

Comment 4 Florian Weimer 2014-06-13 12:23:08 UTC

I think this is better handled with a set of custom NSS modules.  This will be necessary anyway to handle certain corner cases in the way system administrators expect, and glibc is the wrong place for such policy decisions.