Description of problem: When performing a lookup over netgroups using nss_ldap, this one will always return success and print the netgroup even though this one doesn't exist... The issue happens when using setnetgrent(), getnetgrent(), endnetgrent(). The first call to set the nss lookup key will always return 1 (Success) even if it didn't find a result... this makes tools like getent netgroup fake_group always succeed. In fact, getent will do the following: // if (!setnetgrent (key[i])) result = 2; <-- No results found following the manpage, but with nss_ldap we never fall into this case. // Checking the nss_ldap/ldap-nss.c and nss_ldap/ldap-netgrp.c, there are two parts to fix: - by the end of the function that answers to setnetgrent() there is a macro that overrides what ldap_search_s() returns... - in ldap_search_s() there is no notion from where there was no key set, and therefore we miss the result report... I was thinking of something similar to this, it does fix the problem for us. // + /* If we didn't set any key yet (not yet called LOOKUP_SETENT - setXXent()), + * check if we should do it, because if we didn't find any of the results + * then there is no point setting a key. -- jmp + */ + if (sd == NULL && /* No key yet */ + (stat == NSS_SUCCESS && /* No transport issues */ + ldap_count_entries (__session.ls_conn, *res) == 0)) /* No results found */ + { + debug ("<== _nss_ldap_search_s"); + return NSS_NOTFOUND; + } + /* If no entry was returned, try the next search descriptor. */ if (sd != NULL && sd->lsd_next != NULL) { // Version-Release number of selected component (if applicable): nss_ldap-254-2 (rawhide) nss_ldap-226-20 (for this BZ) How reproducible: Always. Steps to Reproduce: 1. Setup /etc/nsswitch.conf with netgroup: files ldap 2. Setup an LDAP directory server with an ldif as follows (optional really as you check non-existant netgroups) -- dn: cn=real,ou=netgroup,dc=seg,dc=redhat,dc=com cn: real ObjectClass: nisNetgroup ObjectClass: top nisNetgroupTriple: (,jmp,) -- 3. Succesful case: % getent netgroup real real (,jmp,) % echo $? 0 4. Failure case: % getent netgroup unreal unreal % echo $? 0 Actual results: Show the non-existant entry and return 0 Expected results: Don't show anything, fall back into return 2 Additional info: [PATCH] attached. Fixes the issue if the query didn't return any contents and we didn't set yet a key. Notice that in the setnetgrent() call, by the end there is that macro that sets the key and doesn't remember if we had or not any successful results from the first ldap_search... This prevents this from happening by testing NSS_NOTFOUND previously returned by the fact the LDAP server returned 0 contents if these were not present. Jose
Created attachment 168960 [details] rawhide patch...
Created attachment 168982 [details] nss_ldap-netgroup_rhel4.patch
If I'm reading it right, the patch won't give you the expected result if you have multiple search descriptors, and the netgroup's data isn't found in the first one (the LDAP search will succeed, you'll get back no answers, and you'll continue on until you run out of search descriptors). Not being able to tell when a group doesn't exist sounds wrong, though.
agreed! this fails if we get multiple queries... looking into the key problem...
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 299215 [details] revised candidate patch Jose, I think this adjusted patch will work. If you've got a system handy for verifying, can you test it?
http://cvs.devel.redhat.com/cgi-bin/cvsweb.cgi/tests/nss_ldap/nss_ldap/bz253997/
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0715.html