Date: Tue, 13 Mar 2007 13:21:01 +0100 From: Gerhard Schmidt <estartu@augusta.de> To: Jonathan McKeown <jonathan@hst.org.za> Cc: freebsd-questions@freebsd.org Subject: Re: nss_ldap and openldap on the same server. Message-ID: <20070313122101.GC20341@augusta.de> In-Reply-To: <200703131113.00673.jonathan@hst.org.za> References: <20070312141915.GA1842@augusta.de> <200703131001.10355.jonathan@hst.org.za> <20070313082613.GA20341@augusta.de> <200703131113.00673.jonathan@hst.org.za>
next in thread | previous in thread | raw e-mail | index | archive | help
--+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2007 at 11:13:00AM +0200, Jonathan McKeown wrote: > On Tuesday 13 March 2007 10:26, Gerhard Schmidt wrote: >=20 > > > It's a well-known problem rather than a bug, and it arises when looki= ng > > > up group information for a user. The system needs a list of all the > > > groups the user is a member of. Since it's a list, not a single answe= r, > > > you can't short-circuit the process with ``success'' after finding a > > > single result: initgroups(3) must work through all possible sources of > > > group information to build the list. > > > > I think its still a bug. You are right that all groups should be found = so > > the default for groups should be success=3Dcontinue to have this done. = But > > when I explicily specify that on success the process should abort, it > > should be done exacly this way. >=20 > You've now had responses from me and Joerg Pulz, and given us essentially= the=20 > same reply. I'm not sure success means what you think it means: group=20 > information is a complete list, not ``first item found'' like a user acco= unt. >=20 > You have told the system to check for group information in files and ldap= . You=20 > have, therefore, not succeeded in listing all groups until you have both= =20 > searched the files *and* received a response from nss_ldap, either group= =20 > information or NSS_STATUS_NOTFOUND. >=20 > It looks as though you can instruct nss_ldap to unconditionally return=20 > NSS_STATUS_NOTFOUND for a user, by adding >=20 > nss_initgroups_ignoreusers user >=20 > in nss_ldap.conf. I'd be interested to hear whether it works, having not= =20 > tested it myself, but at the moment you're banging your head against the = wall=20 > and shouting about how much it hurts. It will hurt less if you stop. It's not. added nss_initgroups_ignoreusers ldap but it still blockes for=20 2 Min. I have found a solution that work for me. The problem is not that=20 nsswitch asks nss_ldap but that nss_ldap take so long to realise the=20 ldap isn't running. I have changed the bind_policy setting of nss_ldap from hard to soft and nss_ldap fails without delay. So it's working for me=20 for now. But still there is a problem with that. Right now there is no way we could prevent any source from adding users to any group (e.g wheel). I think thats a security problem in envoriments where you don't have control over all=20 sources used for authentication und usermanagement. If there was a way you could tell the nss to stop wenn a group definition is found in a module we had a way to stop this. That shouldn't be the default way but it schould be possible.=20 Bye Estartu --=20 ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request=20 Germany | | =20 --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iQCVAwUBRfaXLQzx22nOTJQRAQL6FwP9G46XtMY/0qSFJ7Vay55y7Bphw3zRFs2m tAIAIFwal7GTo45NXMi5HnMlOf43/vhu6i/J6WtAlZAvHG9+QijUYyuBx6o/tfcd aw/l71AZhM1RqqiCPT9fG+4BMooX+2Vwz62EKoXylO2AfrJ0qblxwhY2x2U4tJEc tamOTjbkR2s= =t8Cc -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070313122101.GC20341>