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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"