Max groups at 32?

I'm not sure if this is a Linux capabilities problem, a PAM problem, or what, but I've noticed that If I add a user to > 32 groups...that user cannot access anything in a directory owned by a group > the 32nd group.

Has anyone else experienced this?

Here is a sample script to help troubleshoot if you're interested:

#!/bin/bash
x=34;
useradd testuser
while [ ! $x -lt 1 ]
do groupadd group$x
gpasswd -a testuser group$x
x=$(( $x - 1 ))
done

groups
read
printf "press any key..."
groups testuser
printf "press any key..."
read
mkdir /testdir
chown root:group1 /testdir
chmod 770 /testdir
su - testuser -c "ls /testdir"
printf "press any key..."
read
userdel -r testuser

If all has gone properly, and group1 is *not* in the first groups listing, (not "groups testuser"), then the user will not be able to even ls /testdir, and you'll get permission denied.

Please advise, if you can.
TIA.

Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-698-7250
email: [email protected]

"One ought never to turn one's back on a threatened danger and 
try to run away from it. If you do that, you will double the danger. 
But if you meet it promptly and without flinching, you will 
reduce the danger by half."
Sir Winston Churchill

Yes. It's a hardcoded limit that requires a recompile of both the kernel and glibc to change.

Jeff

Few months ago was release by me shadow package with some neccessary for this changes. From http://shadow.pld.org.pl/ChangeLog:

2001-09-01 Tomasz Kłoczko <[email protected]>

* src/groups.c, src/id.c, src/newgrp.c, src/useradd.c, src/usermod.c, libmisc/addgrps.c, NEWS:
remove limit 32 to groups per user (the same user can belong to
more than 32 groups) by use sysconf(_SC_NGROUPS_MAX) instead constant NGROUPS_MAX (patch by Radu Constantin Rendec <[email protected]>)
NOTE: it probably need testing on other system for add some conditionals
for using sysconf(_SC_NGROUPS_MAX) or NGROUPS_MAX constant.

Some other fixes for correct displaing/handling 32bit uid/gid was after above prepared by Thorsten Kukuk <[email protected]> and me and all was integrated in shadow source tree. All is avalable in latest shadow 4.0.3.

kloczek

-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*

We have a patch floating around that enables unlimited group membership at the kernel level, too. We've never submitted it because it was suggested
that we were crazy and should just bugger off. If I thought it might be
useful and acceptable, we could perhaps make it available in a cleanish form.

Tim

From: Tim Hockin <[email protected]>
Date: Tue, 4 Jun 2002 14:18:22 -0700 (PDT)

We have a patch floating around that enables unlimited group membership at the kernel level, too. We've never submitted it because it was suggested
that we were crazy and should just bugger off. If I thought it might be
useful and acceptable, we could perhaps make it available in a cleanish form.

How do it handle userland backwards compatibility with the existing stuff?

getgroups/setgroups always use a size. use sysctl() to get/set the max ngroups value (default to 32).

It involves some little tweaks at various places, and we keep the groups list sorted because it can now get very large. But all the kernel code is pretty clean. Patching glibc to do the right thing was straight forward. Then a well-done app will call sysctl() to get the ngroups, make room for it and call getgroups().

Old apps that count on NGROUPS being constant will only get the first 32 groups. System admin can define max NGROUPS at boot time via sysctl.

I think I have accurately described it - I didn't write it, so I CC:ed
Erik, who did. It'd be super cool to get this pushed back. I haven't
been trying too hard, but I can definately spend some time prepping it, if it has better than a snowball's chance.

Tim

I screwed up sending this out - just in case it didn't go properly to the list...

getgroups/setgroups always use a size. use sysctl() to get/set the max ngroups value (default to 32).

It involves some little tweaks at various places, and we keep the groups list sorted because it can now get very large. But all the kernel code is pretty clean. Patching glibc to do the right thing was straight forward. Then a well-done app will call sysctl() to get the ngroups, make room for it and call getgroups().

Old apps that count on NGROUPS being constant will only get the first 32 groups. System admin can define max NGROUPS at boot time via sysctl.

I think I have accurately described it - I didn't write it, so I CC:ed
Erik, who did. It'd be super cool to get this pushed back. I haven't
been trying too hard, but I can definately spend some time prepping it, if it has better than a snowball's chance.

Tim

> We have a patch floating around that enables unlimited group > membership at the kernel level, too. We've never submitted it > because it was suggested that we were crazy and should just > bugger off. If I thought it might be useful and acceptable, we > could perhaps make it available in a cleanish form.

Finally, the Linux *BSD cred patch also gets rid of that limit (amongst other things). I haven't updated it since 2.5.3 (and it needs breaking up into smaller patches), but it can still be found under

http://www.fys.uio.no/~trondmy/src/2.5.3/linux-2.5.3-cred.dif

Cheers,
Trond

This is a kernel/glibc limit. If you need complicated permissions like this, you may want to consider using ACLs (see http://acl.bestbits.at/
for ext2/ext3/XFS ACL patches, I don't think Reiserfs has any ACL support).

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/