Bug 113519 - newgrp fails for a particular group if nscd not running
newgrp fails for a particular group if nscd not running
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
8.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Elliot Lee
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-14 16:41 EST by Michael Pelletier
Modified: 2007-04-18 13:01 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-02 15:43:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 16:43 EST, Michael Pelletier
no flags Details
Contents of the main entry for the shasta group (1015 bytes, text/plain)
2004-01-14 16:46 EST, Michael Pelletier
no flags Details

  None (edit)
Description Michael Pelletier 2004-01-14 16:41:10 EST
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
(bac),39003(sitemgr),37(rpm),39029(bcc),39001(xclr_jets),56
(router),501(ste),442(tools),501(ste),120(releng),500,150(smgr)
                                                 ^^^^^
wbl6y012:psmith$ newgrp shasta
newgrp: No such group.: Numerical result out of range
wbl6y012:psmith$ 

Expected results:

wbl6y012:psmith$ id
uid=200384(psmith) gid=1563(neptune) groups=1563(neptune),66(xlr),204
(bac),39003(sitemgr),37(rpm),39029(bcc),39001(xclr_jets),56
(router),501(ste),442(tools),501(ste),120(releng),500(shasta),150
(smgr)                                           ^^^^^^^^^^^^^
wbl6y012:psmith$ newgrp shasta
wbl6y012:psmith$ 

Additional info:
Comment 1 Michael Pelletier 2004-01-14 16:43:41 EST
Created attachment 96994 [details]
strace output from newgrp command w/o nscd
Comment 2 Michael Pelletier 2004-01-14 16:46:06 EST
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:
shasta1:*:500:dtsang,akinari,gkhera,tomyang,christpa,beebes,staplesj,vshanker,rakshah,sujoyde,mterpstr,demerald,mieng,ccoviell,eorejola,rakshah,bbelivea,kingchiu,ausman,davecarr
Comment 3 Michael Pelletier 2004-01-14 16:52:29 EST
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 14:39:25 EST
What happens if you put the shasta group into /etc/group?
Comment 5 Michael Pelletier 2004-02-20 18:15:23 EST
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
(rpm),39001,39029(bcc),56,501,442(tools),204,500(shasta),120
(releng),150(smgr)

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:

  bac:x:204:psmith

and now I can newgrp properly:

  $ id -a
  uid=200384(psmith) gid=1563 groups=1563,66,39003(sitemgr),37
(rpm),39001,39029(bcc),56,501,442(tools),204(bac),500(shasta),120
(releng),150(smgr)

  $ newgrp bac

  $ id -a
  uid=200384(psmith) gid=204(bac) groups=1563,66,39003(sitemgr),37
(rpm),39001,39029(bcc),56,501,442(tools),204(bac),500(shasta),120
(releng),150(smgr)

So, it looks like putting things in /etc/group specifically does fix 
the problem.
Comment 6 Michael Pelletier 2004-02-23 11:49:32 EST
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 
enumeration:
===========
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:
magellan
magellan1
magellan2
magellan3
magellan4
magellanX005

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
3154 
magellan:*:3154:shah,eloy,willo,djevans,seantan,pparch,nebojsab,blah,b
lah,blah...

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 }'
magellan1
magellan4
magellan
magellan2
magellanX005
magellan3

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:

wcary15a >  id
uid=18670(kerly) gid=2159(devo) groups=2159(devo),4086(godzilla),1276
(netgroup_grp),2245
wcary15a >  groups
devo godzilla
netgroup_grp id: cannot find name for group ID 2245
2245
=============
Comment 7 Elliot Lee 2004-12-02 15:43:06 EST
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.