Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 205460 - Using NIS groups with more than 84 members fails
Using NIS groups with more than 84 members fails
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-09-06 11:12 EDT by Timo Ruiter
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-05 11:59:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Timo Ruiter 2006-09-06 11:12:38 EDT
Description of problem:
Inclusion of a group (through NIS) that has more than 84 members fails without
warning.  The system behaves as if that group does not exist. Group rights are
revoked for all members: configured members of that group have that group
stricken from their list of active groups.  All access through group membership
of that group is denied.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a group with many users (but with fewer than 85 members)
2. Assert that one of the members has group rights with id(1): the group is listed.
3. Add some more users, so the total number of members exceeds 84.
4. Assertion of group membership for any member of that group will fail.
Actual results:

Expected results:

Additional info:
Comment 1 Ulrich Drepper 2006-10-05 11:17:09 EDT
I don't have a RHEL3 system here but with an FC5 system I see no client
problems.  I've a group with 92 members and it works fine.  The only limitation
is the total length of the group list as supported by ypserv.

Can you try a FC5/FC6 system and see whether you see a change?  If yes, I need
to know the group you're using.  You can try to disguise the actual group member
names if this doesn't change the outcome.
Comment 2 Timo Ruiter 2006-10-31 07:05:53 EST
The situation is slightly more complex than described earlier, sorry about that.
A user that is member of a group with 84 members is listed as a member of that
group using the 'groups' command.  Adding more members to that group does not
change that: the user is still listed as being a member of that group (now with
more than 84 members).
But when you become that user using 'su' and give the 'id' command the group is
not listed any more!  Change the number of members of that group below 85 and
the group reappears (after re-login of course).  It is not a matter of
displaying group membership incorrectly: the user rights are truly denied so the
'id' command rightly says that the user is not a member of the group.
Comment 3 Jakub Jelinek 2006-10-31 07:16:28 EST
This doesn't answer the questions.
The number of group members isn't sufficient information to reproduce this,
you need to provide the exact group content on which you can reproduce this,
or, if you are worried about posting the exact group name and exact usernames,
try to create another group with made up members that reproduces the same problem
(most probably the exact names don't matter, as long as you keep the lengths
of usernames the same and similarly for username uniqueness).
Comment 4 Ulrich Drepper 2006-10-31 11:18:44 EST
Well, one thing this information does is to point to initgroups() instead of
getgr*() functions.

Regardless, you haven't asnwered whether the problem persists in recent
releases.  FC6 is out.  If you have a RHEL entitlement you can also try RHEL4.

RHEL3 is unlikely to get non-critical changes going forward so a newer code base
is your best bet.
Comment 5 Timo Ruiter 2006-11-01 04:46:25 EST
The group looks like this:


It actually has about 95 members in this example, but that doesn't matter.  (We
use the underscore and letter to distinguish equivalent users in different but
similar environments, possibly running on a single host.  The underscore is a
valid character for userid's, so that should not be a problem, I guess).  All
userid's are at most 8 characters long.
We use NIS and this group is part of it.  Our NIS servers run HP-UX 11.00.  The
RHEL 3 servers run kernel 2.4.21-27.0.4.ELsmp. (Upgrading to the last RHEL3
kernel release is difficult due to cluster software (HP ServiceGuard) not being
certified for that release.)

I would be disappointed if it's true that indeed my best bet is to upgrade to
RHEL4 (yes, we're entitled to it, and yes there seems to be no problem there),
since the system running RHEL3 is a cluster running 24/7.  It is no sinecure to
upgrade this system to RHEL4 because this means a significant kernel change,
leading to redesign of part of our working environments and a lot of testing.
Comment 6 Ulrich Drepper 2006-11-01 12:27:51 EST
> and yes there seems to be no problem there

This means you tested RHEL4 and it works?  Please confirm.

I realize that it is inconvenient to update to RHEL4.  But over the lifetime of
each release it gets by design more and more difficult to add non-critical
changes.  This is something in this category and it hasn't been reported ever
before.  Making a new glibc release is expensive and it'll unlikely happen just
for this issue.  If there are other changes requiring it _and_ we can identify
the changes needed, then it might be possible to get this fixed.  But not otherwise.

There is one thing you could try: take the RHEL4 libnsl and libnss_nis and use
them on the RHEL3 system.  Completely unsupported, of course, but it might work.
Comment 7 Jakub Jelinek 2006-11-21 03:43:53 EST
I have tried to reproduce this with the group you provided and couldn't, both
with (randomly picked) glibc-2.3.2-95.3 and 2.3.2-95.37 (you haven't said what
glibc version you are using).
#include <pwd.h>
#include <grp.h>
#include <stdio.h>

main (void)
  int ng = 1024, i;
  struct passwd *pw = getpwnam("goudse_p");
  gid_t groups[1024];
  int ret = getgrouplist ("goudse_p", pw->pw_gid, groups, &ng);
  if (ret < 0)
    puts ("getgrouplist failed");
  for (i = 0; i < ng; ++i)
    printf ("%d ", groups[i]);
  puts ("");
  return 0;

prints the user's group and 3035, which is this big group coming from NIS.
So, my questions are:
1) what exact glibc release are you using?
2) can you reproduce the problem with initgroups or getgrouplist library calls
   or getent?
3) are you using nscd or not?
Comment 8 Timo Ruiter 2006-12-14 09:35:50 EST
Hello Jakub,

Sorry for the delay, but here are some answers.  The most worrysome part of it
is that I'm not able to repeat the phenomenon.
* We use glibc-2.3.2-93.37.
* Unfortunately your program fails with a segmentation fault in getgrouplist()
when there are more than 9 groups to display (I could not find out why).
* We are using nscd.
On our production system that runs RHEL4 there seems to be no problem.  On of
our main groups has 85 members right now.

So I'm a bit embarrased and confused.  I don't know what has changed since I
reported the bug.  We have installed updates; too much to see which one could
have made a difference.
So probably its best to leave it at that and close it, although I still am not
happy about it.

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