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.)
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?
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)
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.
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)
(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.
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)
(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.
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.
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)