Trying to think out a hack for NSS and pw(8)

Garrett Wollman wollman at
Fri Sep 9 20:04:43 UTC 2016

Presently, we have a bunch of machines under configuration management
(using Puppet, but that's not really relevant here).  I'm hoping to
implement LDAP via nsswitch on these machines, but I've run into an
issue: the standard getpw*(3) mechanisms can't tell the difference
between users or groups in the local databases and those in the remote
LDAP database.  We need Puppet to manage entries for users and groups
in the local database, without respect to what entries might be
imported from LDAP (because they are supposed to override the data
returned by LDAP).  Puppet invokes pw(8) to actually perform the
modifications, but I suspect it also uses native code from the Ruby
standard library to actually do pre-modification lookups.

Looking at the code in both nss-pam-ldapd and libc, it seems like the
only plausible way to fix this is to add functionality to nsswitch
which would allow it to use different configurations depending on the
identity of the process invoking getpwnam(3) or getgrnam(3).  Does
anyone have opinions on how this ought to be implemented, or indeed
how it could be implemented securely?

(As a side issue, the net/nss-pam-ldapd port completely ignores
account expiration dates.  This bug is due to the fact that Linux has
this ships-in-the-night "shadow" mechanism, getspent(3), rather than
having it integrated in getpwent(3) like it should be, but the
ultimate upshot is that if you're using nss-pam-ldapd you can't rely
on shadowExpire attributes in the directory actually have an effect on
FreeBSD.  I'll open a bugzilla issue about this.)


More information about the freebsd-security mailing list