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
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
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/
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 <[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]*
> 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
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?
> 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
>>>>> " " == Tim Hockin <[email protected]> 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
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