Linux (Ubuntu) filter: Why aren't my login supplementary groups correct?

February 2, 2012 11:51 AM

I just upgraded to Ubuntu 10.04. My system is set up to use NIS and autofs. I am able to login and get to nfs-mounted filesystems w/o problem. However my login is just reporting one group membership (as per the 'id' command) whereas it should be reporting 15. I've found that if I su to myself ('su - luge') then all the groups appear. I've also found that if I ssh to another system and ssh back to my system then I only get one group, but if I ssh to another system and *telnet* back to my system then all the groups appear. I've also found that the getgroups(0, NULL) syscall behaves accordingly, returning 1 or 15 depending on the above. Is this some kind of process inheritance issue?
posted by luge to computers & internet (16 answers total)

How many groups does /etc/group show you in? Also, do "id -gn" and "id -Gn" offer different outputs?
posted by introp at 11:56 AM on February 2

/etc/group (local) doesn't have an entry for me, just '+:::' at the end. 'ypcat groups | grep luge | wc -l' shows 15. Both -Gn and -gn return one group.
posted by luge at 12:02 PM on February 2

I don't have a fix or explanation for your problem, but perhaps upgrading to the current version of Ubuntu will help the situation. 10.04 is almost two years old!
posted by number9dream at 12:43 PM on February 2

Ubuntu has a concept that it calls its "main group" and users can only be part of one "main group". However, you can still be part of many groups.
More info is in this forum post
posted by forforf at 1:18 PM on February 2

number9dream,

10.04 is the Long Term Support release and is supported until 2013. Their next LTS release (12.04) isn't until April this year, so 10.04 is an appropriate release if stability is a prime concern.
posted by forforf at 1:25 PM on February 2

Smells like a pam configuration issue if different login routes give rise to different outcomes.
posted by pharm at 1:41 PM on February 2

Dumb question, but have you logged entirely out and back in again? Group membership is only updated on login.
posted by Nelson at 2:01 PM on February 2

Nelson,

Not dumb at all. Did try it w/o success.

pharm,

I wouldn't be surprised if you are correct about pam. unfortunately can't seem to (yet) find the secret :-)
posted by luge at 2:12 PM on February 2

This Debian bug report shows you are not alone, and contains (down the bottom) a possible workaround.
posted by pharm at 2:43 PM on February 2

yeah, PAM sounds like a viable culprit.

also, there's a knob you need to twiddle in Lucid to get NFSv3 group permissions to work correctly if your users have > 8 group memberships (there's only space for 8 gids in the NFS request, so any further groups don't exist as far as the NFS server is concerned). I've had a poke in etckeeper on our server to try and find it but nothing jumps out of the commit logs. I'll ask the other sysad to see if he remembers what it is.
posted by russm at 3:08 PM on February 2

The oddity I see in a quick look is that /etc/pam.d/login has the following:
auth optional pam_group.so

Which none of the other /etc/pam.d/* files have. I looked at login, sshd and su, stripped out comment and blank lines and compared them in a side-by-side diff. The pam_group.so is the only thing that stood out as different, everything else is '@include common-X' and mail/env/nologin/limits/rootok type of stuff. Commenting out that would be my first try.
posted by zengargoyle at 3:25 PM on February 2

ah, OK... the limit is 16 not 8 groups, so you're right for now... but if you ever get more secondary group memberships and need them for NFS permissions you need to remove --manage-gids from the RPCMOUNTDOPTS line in /etc/default/nfs-kernel-server... that one was a giant pain to debug...
posted by russm at 3:26 PM on February 2

come to think of it, I wonder if using the old "+:::" syntax in /etc/group might be confusing something? I believe that's been deprecated for a while... are the passwd/group/shadow entries in nsswitch.conf set to "files nisplus" or to "compat"? you should be able to ditch the plus entries in the local flat files and just use the nsswitch nisplus provider...
posted by russm at 3:45 PM on February 2

metafilter is amazing, as always. Adding nis to the groups line in nsswitch.conf works around the problem. Thanks so much pharm (and everyone)! I doubt that I would have ever found that bug report :-)
posted by luge at 4:55 PM on February 2

The key is to work out what search terms will pull useful information out of Google :)
posted by pharm at 1:33 AM on February 3

(and to know enough about the system to spot a useful solution when you see one of course.)
posted by pharm at 1:33 AM on February 3