[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NIS+ groups, segfaults
From: |
Dirk Wetter |
Subject: |
Re: NIS+ groups, segfaults |
Date: |
Tue, 6 Mar 2001 14:00:27 -0500 (EST) |
Hi,
i am new to this list, i am not even subscribed to it.
but i would appreciate if the bug which we found
(see below) would be fixed *at_least* in the next release.
i couldn't read any mail/notification that this issue
i brought up was addressed, so i though just to step
forward with two suggestions, here they are:
- increase NSS_BUFLEN_GROUP in /usr/include/grp.h
and NSS_BUFLEN_PASSWD in /usr/include/pwd.h
at least to 4096, better 8192.
- somebody has to find the real problem in "_nss_compat_initgroups"
in ./nis/nss_compat/compat-initgroups.c.
the same code seems to be in ./grp/initgroups.c
and ./nis/nss_nis/nis-initgroups.c.
the first one is on one hand an intermediate workaround
and on the other hand a more reasonable initial setting.
it gurantees that for people using NIS+, buflen is in
most of the cases big enough without going a second, third ..
time into the loop. 1024 is just too small, we are a
small company of less than 200 people and that affected us,
because two entries in the group file couldn't fit
into 1k.
the second issue i feel not really able to address, since
i am neither really a libc hacker nor a designer of this whole
thing. it looks only from our perspective that calling twice
__alloca makes the problem. which means imho either fixing
__alloca (ok, might be the wrong list here), or just not to
use __alloca, but something other instead.
ihmo this problem needs to be resolved, also for security reasons.
at least we were able to put some "numbers" on the stack,
which at a certain point was found to be a valid address
be the code after exiting a function.
the compiler the glibc was compiled with was gcc-2.95.2 in
the case we were using the SUSE 7.0 lib, and egcs-2.91.66
if we were using RedHat 6.2 lib.
thx,
~dirkw
On Thu, 1 Mar 2001, Dirk Wetter wrote:
>
> Thorsten,
>
> thx for the answer, hope you had a nice vacation :-).
>
> in the meantime we think we tracked down the culprit,
> it's in our case "_nss_compat_initgroups" in
> "./glibc-2.1/nis/nss_compat/compat-initgroups.c".
> just increasing the buflen before the first time calling
> the "while" loop helps. the whole is more a workaround
> of course. the real culprit is probably __alloca.
> internal_getgrent_r returns with NSS_STATUS_TRYAGAIN
> for the first one since of our big NIS+ groups don't fit
> into 1024 bytes, the second time __alloca
> is being called it corrupts the stack somehow. the segfault
> is way later, when another function exits.
>
> as a quick and better workaround we thought we could increase
> NSS_BUFLEN_PASSWD which 1024 (the value actually returned
> by sysconf (_SC_GETPW_R_SIZE_MAX)... howto do that? looks
> like it is not a parameter which is tunable during runtime?
>
>
> ~dirkw
>
>
> PS: that piece of code seems to be the same for glibc 2.2.2
>
>
> On Thu, 1 Mar 2001, Thorsten Kukuk wrote:
>
> > On Wed, Feb 28, Dirk Wetter wrote:
> >
> > >
> > > Hi all,
> > >
> > > below you find a mail posted in November 2000 to the NIS+
> > > Linux mailing list. Looks also for us like there's a
> > > problem, which hasn't been fixed. I know that we are
> > > using not the very recent libc, but I like to find out where
> > > the problem is anyhow.
> > >
> > > We are using a plain SuSE 7.0 with a libc-2.1.3.
> > > We have 2 groups with more than 700 chars, as soon as
> > > we enable the compat or nisplus mode in /etc/nsswitch.conf for
> > > groups we get segfaults while authenticating. also the strace
> > > output makes us assuming that there is a bug. No problem if
> > > we dump the NIS+ groups and append it to /etc/group.
> > >
> > > So, how can we find the bug and to fix it in libc 2.1.3 ??
> >
> > The last time I had access to a NIS+ server I couldn't reproduce
> > any problems with NIS+ groups. But it looks like there is one
> > problem with netgroups and static linking and one with the
> > initgroups function. Nobody was yet able to track them down.
> >
> > Thorsten
> >
> > --
> > Thorsten Kukuk http://www.suse.de/~kukuk/ address@hidden
> > SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg
> > Linux is like a Vorlon. It is incredibly powerful, gives terse,
> > cryptic answers and has a lot of things going on in the background.
> >
>
>
>