From owner-freebsd-arch@freebsd.org Sat Sep 10 06:01:49 2016 Return-Path: Delivered-To: freebsd-arch@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 19711BD2A38; Sat, 10 Sep 2016 06:01:49 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5EA0C68; Sat, 10 Sep 2016 06:01:47 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-f0fff70000003e0f-39-57d3a096e235 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id B3.68.15887.690A3D75; Sat, 10 Sep 2016 01:56:38 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u8A5ub3B004390; Sat, 10 Sep 2016 01:56:37 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8A5uYdh005897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Sep 2016 01:56:36 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8A5uXrW029071; Sat, 10 Sep 2016 01:56:33 -0400 (EDT) Date: Sat, 10 Sep 2016 01:56:33 -0400 (EDT) From: Benjamin Kaduk To: Garrett Wollman cc: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: Re: Trying to think out a hack for NSS and pw(8) In-Reply-To: <22483.5592.653250.726711@hergotha.csail.mit.edu> Message-ID: References: <22483.5592.653250.726711@hergotha.csail.mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixG6nrjttweVwgxMHJC1mT5/GZNGz6Qmb xY5Pd9kdmD0uTb3N6jHj03yWAKYoLpuU1JzMstQifbsErowJ+04zFqzjqVi1rZ+pgfEfZxcj J4eEgInEurVtbF2MXBxCAm1MEt2HbzJBOBsZJRo6l7NDOIeYJI51nGcBaRESaGCUeP8tFMRm EdCW2LbnNDOIzSagIjHzzUagURwcIgI6EkuX8YCEmQWsJE6+WMYKYgsLWEq0/rzBBmJzCthJ /JzwgB3E5hVwkHi66TYLSKuQgK3EtA0mIGFRoCmr909hgSgRlDg58wkLxEgtieXTt7FMYBSY hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0TvdzMEr3UlNJNjKDA5JTk38E4p8H7 EKMAB6MSD++G3ZfChVgTy4orcw8xSnIwKYnyXtO7HC7El5SfUpmRWJwRX1Sak1p8iFGCg1lJ hHfuDKAcb0piZVVqUT5MSpqDRUmct2vGgXAhgfTEktTs1NSC1CKYrAwHh5IE77n5QI2CRanp qRVpmTklCGkmDk6Q4TxAw3tAaniLCxJzizPTIfKnGBWlxHkZQBICIImM0jy4XnDi2M2k+opR HOgVYd6lIFU8wKQD1/0KaDAT0GChU+dBBpckIqSkGhhbf8zKuui8yslsl2Xr1tl7mZa5v1ub KW+aY3E50vvwM4t3sUkzrqRIXlO1bGh9sIF9nuCciF/hbzNXCaXxKPKEp7Du45F7UbIs/Zd+ nqfI0hsXJi/q1zcWCTG3dyyTEfl0X5Xh0VzZ2Gsb1dtN2HoFbu9qlD6wQ2h/7DqGZcLBwXru Ihe2P1FiKc5INNRiLipOBAAGbO9I9wIAAA== X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 06:01:49 -0000 On Fri, 9 Sep 2016, Garrett Wollman 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? It's a bit late here, but it sounds kind of like you want to be able to set NSS_NONLOCAL_IGNORE [and have it do something useful]? (https://debathena.mit.edu/nss_nonlocal/) Unfortunately, I never got far enough in trying to port Athena to FreeBSD to have looked at how portable nss_nonlocal is. But it is probably worth looking at, for your case. -Ben