Bug 205460

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.

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.

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

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.

The group looks like this:

sduid_p::3035:bbnamr_p,bevita_p,cgis_p,cmfora_p,dvz_p,hortis_p,gelre_p,
goudse_p,iak_p,interb_p,intere_p,interp_p,ivw_p,izz_p,knvd_p,mindep_p,nbdb_p,
nova_p,nsx_p,redojc_p,siz_p,slp_p,trais_p,unevo_p,vgz_p,zolver_p,pds,
pustbe_p,slp_p,nova_p,ns_p,ivw_p,manbyk_p,rdw_p,straat01,straat02,straat03,
straat04,straat05,straat06,straat07,straat08,straat09,straat10,straat11,
straat12,straat13,straat14,straat15,straat16,verpak01,verpak02,verpak03,
verpak04,verpak05,verpak06,verpak07,verpak08,verpak09,verpak10,verpak11,
verpak12,kluis01,kluis02,kluis03,kluis04,adriaanm,marcelb,meinovdw,nielsb,
hansvs,harmdb,frankdb,ronb,voorman,joopvdv,arnom,bertvdk,ronaldn,willemh,
rikvo,steevel,steveno,titusd,bartj,ralphr,keesv,harmp,robbu,ankob,michelp,
knvb_p,tons,rontv

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.

> 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.

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).
E.g.
#include <pwd.h>
#include <grp.h>
#include <stdio.h>

int
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?

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.