Bug 253997 - nss_ldap / setnetgrent() returns always 1 despite not retrieving any valid results.
Summary: nss_ldap / setnetgrent() returns always 1 despite not retrieving any valid re...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap
Version: 4.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-23 15:04 UTC by Jose Plans
Modified: 2008-07-24 19:55 UTC (History)
1 user (show)

Fixed In Version: RHSA-2008-0715
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-24 19:55:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
rawhide patch... (1.23 KB, patch)
2007-08-23 15:04 UTC, Jose Plans
no flags Details | Diff
nss_ldap-netgroup_rhel4.patch (1.22 KB, patch)
2007-08-23 15:09 UTC, Jose Plans
no flags Details | Diff
revised candidate patch (1.23 KB, patch)
2008-03-26 19:20 UTC, Nalin Dahyabhai
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0715 0 normal SHIPPED_LIVE Low: nss_ldap security and bug fix update 2008-07-24 16:57:16 UTC

Description Jose Plans 2007-08-23 15:04:19 UTC
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

Comment 1 Jose Plans 2007-08-23 15:04:21 UTC
Created attachment 168960 [details]
rawhide patch...

Comment 2 Jose Plans 2007-08-23 15:09:03 UTC
Created attachment 168982 [details]
nss_ldap-netgroup_rhel4.patch

Comment 3 Nalin Dahyabhai 2007-08-23 15:58:13 UTC
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.

Comment 4 Jose Plans 2007-08-23 16:14:15 UTC
agreed! this fails if we get multiple queries... looking into the key problem...


Comment 5 RHEL Program Management 2007-11-29 03:59:23 UTC
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.

Comment 9 Nalin Dahyabhai 2008-03-26 19:20:02 UTC
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?

Comment 14 errata-xmlrpc 2008-07-24 19:55:39 UTC
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


Note You need to log in before you can comment on or make changes to this bug.