From owner-freebsd-questions@FreeBSD.ORG Tue Mar 13 09:12:05 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF6F516A401 for ; Tue, 13 Mar 2007 09:12:05 +0000 (UTC) (envelope-from jonathan@hst.org.za) Received: from sirian.hst.org.za (sirian.hst.org.za [209.203.2.130]) by mx1.freebsd.org (Postfix) with ESMTP id 3183513C46E for ; Tue, 13 Mar 2007 09:11:55 +0000 (UTC) (envelope-from jonathan@hst.org.za) Received: from localhost (localhost.hst.org.za [127.0.0.1]) by sirian.hst.org.za (Postfix) with ESMTP id EFB8B31D341 for ; Tue, 13 Mar 2007 11:08:08 +0200 (SAST) Received: from sirian.hst.org.za ([127.0.0.1]) by localhost (sirian.hst.org.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95214-03 for ; Tue, 13 Mar 2007 11:08:08 +0200 (SAST) Received: from sysadmin.int.dbn.hst.org.za (sysadmin.int.dbn.hst.org.za [10.1.1.20]) by sirian.hst.org.za (Postfix) with ESMTP id 7D66631CF37 for ; Tue, 13 Mar 2007 11:08:08 +0200 (SAST) From: Jonathan McKeown Organization: Health Systems Trust To: freebsd-questions@freebsd.org Date: Tue, 13 Mar 2007 11:13:00 +0200 User-Agent: KMail/1.7.2 References: <20070312141915.GA1842@augusta.de> <200703131001.10355.jonathan@hst.org.za> <20070313082613.GA20341@augusta.de> In-Reply-To: <20070313082613.GA20341@augusta.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703131113.00673.jonathan@hst.org.za> X-Virus-Scanned: by amavisd-new at hst.org.za Subject: Re: nss_ldap and openldap on the same server. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2007 09:12:05 -0000 On Tuesday 13 March 2007 10:26, Gerhard Schmidt wrote: > > It's a well-known problem rather than a bug, and it arises when looking > > 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 answer, > > 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=continue to have this done. But > when I explicily specify that on success the process should abort, it > should be done exacly this way. You've now had responses from me and Joerg Pulz, and given us essentially the same reply. I'm not sure success means what you think it means: group information is a complete list, not ``first item found'' like a user account. You have told the system to check for group information in files and ldap. You have, therefore, not succeeded in listing all groups until you have both searched the files *and* received a response from nss_ldap, either group information or NSS_STATUS_NOTFOUND. It looks as though you can instruct nss_ldap to unconditionally return NSS_STATUS_NOTFOUND for a user, by adding nss_initgroups_ignoreusers user in nss_ldap.conf. I'd be interested to hear whether it works, having not tested it myself, but at the moment you're banging your head against the wall and shouting about how much it hurts. It will hurt less if you stop. Jonathan