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:
Created attachment 96994 [details] strace output from newgrp command w/o nscd
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
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
What happens if you put the shasta group into /etc/group?
We have determined that later releases of the kernel/glibc do not exhibit this behaviour. Test results from Paul Smith, psmith: ============= 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.
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 =============
Sounds like it's fixed in newer releases.