Bug 113519 - newgrp fails for a particular group if nscd not running
Summary: newgrp fails for a particular group if nscd not running
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-14 21:41 UTC by Michael Pelletier
Modified: 2007-04-18 17:01 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-02 20:43:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace output from newgrp command w/o nscd (26.28 KB, text/plain)
2004-01-14 21:43 UTC, Michael Pelletier
no flags Details
Contents of the main entry for the shasta group (1015 bytes, text/plain)
2004-01-14 21:46 UTC, Michael Pelletier
no flags Details

Description Michael Pelletier 2004-01-14 21:41:10 UTC
Description of problem:
See below.

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

How reproducible: Every time

Steps to Reproduce:
1. Stop nscd daemon
2. Log in as a secondary member of the group
3. Issue "newgrp shasta" command or "id" command
Actual results:

wbl6y012:psmith$ id
uid=200384(psmith) gid=1563(neptune) groups=1563(neptune),66(xlr),204
wbl6y012:psmith$ newgrp shasta
newgrp: No such group.: Numerical result out of range

Expected results:

wbl6y012:psmith$ id
uid=200384(psmith) gid=1563(neptune) groups=1563(neptune),66(xlr),204
(smgr)                                           ^^^^^^^^^^^^^
wbl6y012:psmith$ newgrp shasta

Additional info:

Comment 1 Michael Pelletier 2004-01-14 21:43:41 UTC
Created attachment 96994 [details]
strace output from newgrp command w/o nscd

Comment 2 Michael Pelletier 2004-01-14 21:46:06 UTC
Created attachment 96995 [details]
Contents of the main entry for the shasta group

The group also has an adjunct entry in the NIS database called "shasta1" with
the same GID, but the user account in which I ran the strace and tests is in
the main entry.

Here is the adjunct group entry:

Comment 3 Michael Pelletier 2004-01-14 21:52:29 UTC
The problem group, "shasta", is a fairly long group, but it is under 
the 1000-byte line length limit for the NIS database.

I tried cutting the length of the line in half, thinking that perhaps 
the NSS_BUFLEN_GROUP, set to 1024 in the grp.h file, was being 
overrun due to the overhead involved in the linked list pointers in 
the group membership portion of the "struct group" value, but it made 
no difference to the error message displayed when nscd is not running.

When nscd is running, everything operates perfectly normally.

The nsswitch.conf entry is "group: files nis", and there is no entry 
for shasta or gid 500 in the /etc/group file.

Even without nscd running, attempts to newgrp to other secondary 
groups, such as "ste", work fine.

NSCD: glibc-2.2.93-5
YPBIND: ypbind-1.11-2

Comment 4 Elliot Lee 2004-02-20 19:39:25 UTC
What happens if you put the shasta group into /etc/group?

Comment 5 Michael Pelletier 2004-02-20 23:15:23 UTC
We have determined that later releases of the kernel/glibc do not 
exhibit this behaviour.

Test results from Paul Smith, psmith@nortelnetworks.com:
Oh yeah.  I just shut down nscd on wbl6y085 and I see it in spades:

  $ id -a
  uid=200384(psmith) gid=1563 groups=1563,66,39003(sitemgr),37

For example, gid 204 is "bac", but:

  $ newgrp bac
  newgrp: No such group.: Numerical result out of range

So, I added to /etc/group this line:


and now I can newgrp properly:

  $ id -a
  uid=200384(psmith) gid=1563 groups=1563,66,39003(sitemgr),37

  $ newgrp bac

  $ id -a
  uid=200384(psmith) gid=204(bac) groups=1563,66,39003(sitemgr),37

So, it looks like putting things in /etc/group specifically does fix 
the problem.

Comment 6 Michael Pelletier 2004-02-23 16:49:32 UTC
Debugging work from Dave Kerlovich suggests that this may be a result 
of the order in which the adjunct groups are returned during a map 
From: 	Kerlovich, David [CAR:W669:EXCH]  
Sent:	Saturday, February 14, 2004 1:35 AM
To:	Reade, Michael [Business:CAR:C01S]
Cc:	Pelletier, Michael; Baker, Howard
Subject:	Problem resolving NIS groups in Linux

I got home from hockey late and my brain was still working so I could 
not get to sleep.

Michael Reade, the magellan group (and a number of others) have been 
divided up into adjunct groups with the same GID. This we have to do 
as there is a 1024 character limit to any NIS record.

So there are actually 6 groups with GID 3154:

We used to do this manually and name each by increasing the last 
number. Now it is auto generated hence the "X005" suffix.

But the group.bygid map must and does have only one entry so that the 
GID resolves to the correct name:

wcary15a >  ypcat -k group.bygid  | grep 3154

If Linux is trying to lookup the GID 3154 in the group.byname map (by 
traversing a ypcat) it might get confused The order of the records 
you get when you do a ypcat is not deterministic. For example:

zcars0ph #   ypcat -k group | grep ":3154:" | awk '{ print $1 }'

To test this theory I added my userID as a member of the synergy 
adjunct group synergy_X002 (GID 2245) and I see the same behaviour on 

wcary15a >  id
uid=18670(kerly) gid=2159(devo) groups=2159(devo),4086(godzilla),1276
wcary15a >  groups
devo godzilla
netgroup_grp id: cannot find name for group ID 2245

Comment 7 Elliot Lee 2004-12-02 20:43:06 UTC
Sounds like it's fixed in newer releases.

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