Max groups at 32?

Max groups at 32?

[Austin Gonyou]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

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: austin@coremetrics.com

"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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: Max groups at 32?

[Jeff Garzik]

Austin Gonyou wrote:

>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.
>  
>


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

    Jeff

Re: Max groups at 32?

[Andreas Dilger]

On Jun 03, 2002  22:31 -0500, Austin Gonyou wrote:
> 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.

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/

Re: Max groups at 32?

[Tomasz Kłoczko]

On Mon, 3 Jun 2002, Jeff Garzik wrote:

> Austin Gonyou wrote:
> 
> >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.
> >  
> >
> 
> 
> Yes.  It's a hardcoded limit that requires a recompile of both the 
> kernel and glibc to change.

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  <kloczek@pld.org.pl>

        * 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 <radu.rendec@ines.ro>)
        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 <kukuk@suse.de> 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: kloczek@rudy.mif.pg.gda.pl*

Re: Max groups at 32?

[Tim Hockin]

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

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

Re: Max groups at 32?

[David S. Miller]

   From: Tim Hockin <thockin@hockin.org>
   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?

Re: Max groups at 32?

[Tim Hockin]

>    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

Re: Max groups at 32?

[Trond Myklebust]

>>>>> " " == Tim Hockin <thockin@hockin.org> writes:

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

     > 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

Re: Max groups at 32?

[Tim Hockin]

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


>    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