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

[Jan Mikkelsen]

Hi,

We have system images under version control with password databases as part of the system image which get merged with system-specific password databases. Not exactly the same requirement but similar.

We manage the two separate databases using the -V option to pw, and then have a script to merge the two databases into the standard local database. This runs on boot to bring in changes from the system image build, and after a local system change to apply the change. The problem with your environment is probably that you’re calling getpwnam, etc., where you can’t specify which password database you want to use.

If you changed the code that should only view local changes to use “pw -V /path/to/local usershow” instead of calling getpw*(), a similar approach might be possible.

Regards,

Jan.


> On 10 Sep 2016, at 06:04, Garrett Wollman <wollman at bimajority.org> wrote:
> 
> 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.)
> 
> -GAWollman
> 
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"