Date: Sat, 10 Sep 2016 17:31:02 +1000 From: Jan Mikkelsen <janm@transactionware.com> To: Garrett Wollman <wollman@bimajority.org> Cc: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: Re: Trying to think out a hack for NSS and pw(8) Message-ID: <C924FA73-283C-4120-9F18-7BEF8B465DF4@transactionware.com> In-Reply-To: <22483.5592.653250.726711@hergotha.csail.mit.edu> References: <22483.5592.653250.726711@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E2=80=99re calling getpwnam, = etc., where you can=E2=80=99t specify which password database you want = to use. If you changed the code that should only view local changes to use =E2=80=9C= pw -V /path/to/local usershow=E2=80=9D instead of calling getpw*(), a = similar approach might be possible. Regards, Jan. > On 10 Sep 2016, at 06:04, Garrett Wollman <wollman@bimajority.org> = wrote: >=20 > 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. >=20 > 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? >=20 > (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.) >=20 > -GAWollman >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C924FA73-283C-4120-9F18-7BEF8B465DF4>