[Bug nis/962] New: traditional netgroup logins impossible

[Bug nis/962] New: traditional netgroup logins impossible

[dvandeun at wilma dot vub dot ac dot be]

Since 2.3.4 using netgroups the old-fashioned way (+@ in /etc/passwd) does
not work anymore.  Trying to log in through such a group gives:

-bash: nss_nis/nis-netgrp.c:79: _nss_nis_setnetgrent: Assertion
`malloc_usable_size (netgrp->data) >= len + 1' failed.

Everything actually works fine without that assert statement (well, it did
in 2.3.4, I haven't really tested 2.3.5 yet, only noticed the problem
again.)

(Problem encountered on slackware i486, i.e. very vanilla, no PAM.)

-- 
           Summary: traditional netgroup logins impossible
           Product: glibc
           Version: 2.3.5
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nis
        AssignedTo: kukuk at suse dot de
        ReportedBy: dvandeun at wilma dot vub dot ac dot be
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[kukuk at suse dot de]

------- Additional Comments From kukuk at suse dot de  2005-05-27 10:15 -------
I'm not able to reproduce that, works fine for me.  
  
>From where do you get your netgroups? /etc/netgroup or NIS?  
  
If you add a printf before the assert and prints out   
malloc_usable_size (netgrp->data) and len, what is the output? 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[dvandeun at wilma dot vub dot ac dot be]

------- Additional Comments From dvandeun at wilma dot vub dot ac dot be  2005-05-30 15:59 -------
Subject: Re:  traditional netgroup logins impossible

> I'm not able to reproduce that, works fine for me.  
>   
> >From where do you get your netgroups? /etc/netgroup or NIS?  

>From NIS, just like the account information.

> If you add a printf before the assert and prints out   
> malloc_usable_size (netgrp->data) and len, what is the output? 

root@progpc25:/data/build/glibc-2.3.5/build-glibc-2.3.5/nis# su - dvandeun
[size: 1004, len: 1002][size: 1004, len: 999]No directory, logging in with HOME=/
-su: nss_nis/nis-netgrp.c:80: _nss_nis_setnetgrent: Assertion `malloc_usable_size (netgrp->data) >= len + 1' failed.
[size: 992, len: 1002]Aborted
root@progpc25:/data/build/glibc-2.3.5/build-glibc-2.3.5/nis#

Dirk van Deun
--
Licensed to (kill -9)


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[bugzilla1 at malloc dot de]

------- Additional Comments From bugzilla1 at malloc dot de  2005-06-13 09:13 -------
Can you re-run your command with MALLOC_CHECK_=2 set in the environment?
Or even better, run against a glibc compiled with MALLOC_DEBUG defined?
I suspect an earlier bug corrupting malloc's internal data structures.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[dvandeun at wilma dot vub dot ac dot be]

------- Additional Comments From dvandeun at wilma dot vub dot ac dot be  2005-06-14 10:48 -------
Subject: Re:  traditional netgroup logins impossible

> Can you re-run your command with MALLOC_CHECK_=2 set in the environment?
> Or even better, run against a glibc compiled with MALLOC_DEBUG defined?
> I suspect an earlier bug corrupting malloc's internal data structures.

Tried both, nothing happens.  Not visibly, at least.

In the meantime, I found that running nscd seems to be a functional
work-around.  (Which also means that to test the problem, you
should disable nscd.)

Dirk van Deun
--
Licensed to (kill -9)


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[kukuk at suse dot de]

------- Additional Comments From kukuk at suse dot de  2005-06-27 13:47 -------
(In reply to comment #4) 
> In the meantime, I found that running nscd seems to be a functional 
> work-around.  (Which also means that to test the problem, you 
> should disable nscd.) 
 
Which sounds like the problem is your application calling the getpw*() 
functions and not glibc. 

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[dvandeun at wilma dot vub dot ac dot be]

------- Additional Comments From dvandeun at wilma dot vub dot ac dot be  2005-06-27 14:40 -------
Subject: Re:  traditional netgroup logins impossible

> > In the meantime, I found that running nscd seems to be a functional 
> > work-around.  (Which also means that to test the problem, you 
> > should disable nscd.) 
>  
> Which sounds like the problem is your application calling the getpw*() 
> functions and not glibc. 

Then how do you explain that I could fix it by removing an assert from
glibc ?

Dirk van Deun
--
Licensed to (kill -9)


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[kukuk at suse dot de]

------- Additional Comments From kukuk at suse dot de  2005-06-27 14:43 -------
(In reply to comment #6) 
> Subject: Re:  traditional netgroup logins impossible 
>  
> > > In the meantime, I found that running nscd seems to be a functional  
> > > work-around.  (Which also means that to test the problem, you  
> > > should disable nscd.)  
> >   
> > Which sounds like the problem is your application calling the getpw*()  
> > functions and not glibc.  
>  
> Then how do you explain that I could fix it by removing an assert from 
> glibc ? 
 
You don't fix it, you hide it. Removing the check only means, the program will 
not fail at this place, not that the bug is fixed which makes this check fail. 
 

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[kukuk at suse dot de]

------- Additional Comments From kukuk at suse dot de  2005-07-04 07:57 -------
I'm not able to reproduce it. And since it does not happen if nscd is 
running, it looks like as if your application is corrupting the memory. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nis/962] traditional netgroup logins impossible

[dvandeun at wilma dot vub dot ac dot be]

------- Additional Comments From dvandeun at wilma dot vub dot ac dot be  2005-07-04 10:10 -------
Subject: Re:  traditional netgroup logins impossible

> I'm not able to reproduce it. And since it does not happen if nscd is 
> running, it looks like as if your application is corrupting the memory. 

But both variables in the failing check

  assert (malloc_usable_size (netgrp->data) >= len + 1);

are set a few lines higher by

  yp_match (domain, "netgroup", group, strlen (group),
                                &netgrp->data, &len)

and yp_match builds up the contents of these variables:

  yp_match (const char *indomain, const char *inmap, const char *inkey,
            const int inkeylen, char **outval, int *outvallen)
  {
    (...deleted the branches that do not return SUCCESS...)
  
    *outvallen = resp.val.valdat_len;               <----------
    *outval = malloc (*outvallen + 1);              <----------
    if (__builtin_expect (*outval == NULL, 0))
      return YPERR_RESRC;
    memcpy (*outval, resp.val.valdat_val, *outvallen);
    (*outval)[*outvallen] = '\0';
  
    xdr_free ((xdrproc_t) xdr_ypresp_val, (char *) &resp);
  
    return YPERR_SUCCESS;
  }

So the relevant malloc is done inside glibc, and the length of *outval
(i.e. netgrp->data) should be at least *outvallen (i.e. len) + 1.

So it looks very much as if the malloc_usable_size is the only thing
left that could go wrong in:

  assert (malloc_usable_size (netgrp->data) >= len + 1);

Interestingly, this is the *only* place in the whole of glibc where
mallow_usable_size is used.

Dirk van Deun
--
Licensed to (kill -9)


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=962

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.