Bug 130363

Summary: cannot log in if listed in many groups [segfault in getgrent_next_nss]
Product: [Fedora] Fedora Reporter: Ian Collier <imc>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 2CC: drepper
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: 2.3.3-45 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 09:50:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
traceback from gdb at the point of impact none

Description Ian Collier 2004-08-19 17:12:20 UTC 
Description of problem:
A particular user tries to ssh in to an FC2 machine but gets
"Read from remote host xyz: Connection reset by peer".  On
investigation, if root tries to su to this user the result
is "Segmentation fault".  There are three users to whom this
applies, and they are all members of 12 or more groups.

The password and group information is held on a NIS server,
with the last line in the /etc/group file being "+" and 
/etc/nsswitch.conf containing the token "compat".

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

How reproducible:
Always - at least on this particular machine.

Steps to Reproduce:
1. Set up a NIS server with passwd and group information.
2. Set up a Fedora Core 2 machine as a NIS client.  End the
   /etc/group file on the FC2 machine with "+" and set
   the /etc/nsswitch.conf entry for the group file to "compat".
3. Add a user to at least 12 groups on the NIS server.
4. Log in to the FC2 machine as root and try to su to this user.
  
Actual results:
Segmentation fault.

Expected results:
Successful login.

Additional info:

The following is my opinion of why it crashes:

nis/nss_compat/compat-initgroups.c line 245 says:

      gid_t *mygroupsp = __alloca (limit * sizeof (gid_t));

The value "limit" is a parameter passed in, ultimately from code
in the function getgrouplist() at grp/initgroups.c line 210:

  result = internal_getgrouplist (user, group, &size, &newgroups, -1);

Here the limit is specified as "-1".  Hence, __alloca is being 
called with a negative parameter.  Having seen that, I have no idea
why it doesn't crash every time instead of just for those users
who are in many groups.
Comment 1 Ian Collier 2004-08-19 17:14:01 UTC 
Created attachment 102886 [details]
traceback from gdb at the point of impact
Comment 2 Ulrich Drepper 2004-09-30 09:50:59 UTC 
This is fixed in FC3t2.