From owner-freebsd-security@freebsd.org Sat Sep 10 07:37:46 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F6EABD4F9A for ; Sat, 10 Sep 2016 07:37:46 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id DD5FF83B for ; Sat, 10 Sep 2016 07:37:44 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 36997 invoked by uid 907); 10 Sep 2016 07:31:01 -0000 Received: from eth222.nsw.adsl.internode.on.net (HELO [192.168.1.101]) (150.101.196.221) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Sat, 10 Sep 2016 17:31:01 +1000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Trying to think out a hack for NSS and pw(8) From: Jan Mikkelsen In-Reply-To: <22483.5592.653250.726711@hergotha.csail.mit.edu> Date: Sat, 10 Sep 2016 17:31:02 +1000 Cc: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <22483.5592.653250.726711@hergotha.csail.mit.edu> To: Garrett Wollman X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Sat, 10 Sep 2016 11:22:35 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 07:37:46 -0000 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 = 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"