Bug#121705: libc6: initgroups() in su does not initialize all NIS+ groups

[Patrick Ohly]

On Fri, 2001-11-30 at 14:48, Ben Collins wrote:
> On Fri, Nov 30, 2001 at 09:52:09AM +0100, Patrick Ohly wrote:
[initgroups() does not set groups reliably]

> Look, here's the long of it. Initgroups works in all other
> configurations (NIS, LDAP, flatfile). So initgroups() is not broken.
> That's the end of that argument.

Now I see where we went down the wrong tangent - I never meant to say
that initgroups() itself and not one of the function or the server
it calls is broken.

I only observed that initgroups() does not work reliably, and as
I didn't have the time to dig into its source I was hoping to get
some help or guidance by reporting my problem.

I understand now that I should probably have asked elsewhere first,
as its clearly not your task to investigate a problem unless it is
clear that it is not caused by a broken configuration or broken
server software.

Therefore I have added linux-nisplus at lists.samba.org as cc
in the hope that someone there might have the time to advise me.
Ben, please let me know if you want me stop informing you about my
findings.

Anyway, I traced through libc6-dbg after downloading the source
package and found that it fails in getgrent_next_nisplus:

(gdb) where
#0  getgrent_next_nisplus (result=0xbffffbac, ent=0xbffffb80, 
    buffer=0xbffff754 "uucp", buflen=1024, errnop=0x40133e60)
    at nss_compat/compat-initgroups.c:346
#1  0x40141abf in internal_getgrent_r (gr=0xbffffbac, ent=0xbffffb80, 
    buffer=0xbffff754 "uucp", buflen=1024, errnop=0x40133e60)
    at nss_compat/compat-initgroups.c:583
#2  0x40141b81 in _nss_compat_initgroups_dyn (user=0xbffffe4f "toolpst",
    group=0, start=0xbffffc14, size=0xbffffc64, groupsp=0xbffffc68,
limit=32, 
    errnop=0x40133e60) at nss_compat/compat-initgroups.c:614
#3  0x400b89c0 in internal_getgrouplist (user=0xbffffe4f "toolpst",
group=0, 
    size=0xbffffc64, groupsp=0xbffffc68, limit=32) at initgroups.c:174
#4  0x400b8b1e in initgroups (user=0xbffffe4f "toolpst", group=0)
    at initgroups.c:260
#5  0x08048585 in main (argc=2, argv=0xbffffd54) at testinitgroups.c:13
#6  0x4003365f in __libc_start_main (main=0x8048540 <main>, argc=2, 
    ubp_av=0xbffffd54, init=0x804839c <_init>, fini=0x80486a0 <_fini>, 
    rtld_fini=0x4000b1e0 <_dl_fini>, stack_end=0xbffffd4c)
    at ../sysdeps/generic/libc-start.c:129

(gdb) print ent->result->status
$5 = NIS_BADREQUEST

This is translated into NSS_STATUS_UNAVAIL, so
_nss_compat_initgroups_dyn() stops parsing the NIS+ group
and goes to done (line 620 of nss_compat/compat-initgroups.c),
but _without_ indicating that there was an error.

Therefore initgroups() proceeds with an incomplete group list.

I roughly found where this NIS_BADREQUEST comes from:
I have seen that res->status == NIS_SUCCESS immediately before
__do_niscall() in nis_next_entry() of nis_table.c, but then
this call set res->status to NIS_BADREQUEST while returning
status == NIS_SUCCESS.

Is this behaviour okay? I'd expect a function that returns okay
not to set an error code elsewhere. If this is correct and the
return code overrides the error code, then nis_next_entry()
would have to set res->status always and not just in case of
an error (as it does now).

> What _is_ broken is something further down the line that initgroups()
> relies on. Either the NIS+ NSS library (found in libc), which I already
> know works for quite a few other people.

Unfortunately it doesn't for me, so I'd really appreciate some help
here. I am advocating the replacement of Solaris x86 autoclients 
with Debian right now, and if this problem cannot be solved we would
have to try either another Linux distribution or forget about Linux
on our desktops. If it is a Debian specific problem (which I don't
know and don't believe right now), then I have praised Debian too much
for its reliability, and otherwise we would end up with Windows - I hope
you understand that I am really interested in any kind of solution.

-- 
Freundliche Gruesse / Best Regards

Patrick Ohly
Software Engineer
--------------------------------------------------------------------
//// pallas 
Pallas GmbH / Hermuelheimer Str. 10 / 50321 Bruehl / Germany
Patrick.Ohly at pallas.com / www.pallas.com
Tel +49-2232-1896-30 / Fax +49-2232-1896-29
--------------------------------------------------------------------