Hi Frank,
I'm aware of the patch. In fact I've spent far too much time researching
the > 16 groups problem as I'm sure so many others have. It's so sad the
nfs designers made that gid list a fixed length array. Anyway ..
There are two reasons we don't use your patch:
* It's not a standard part of the kernel. So we have to always patch.
This can be painful for our junior admins for new versions.
* The major reason though is that we run OSX and IRIX as well linux. By
using setgroups everywhere we solve our problem for all cases, including
the proprietary OS's for which we don't have source. This is a big deal.
I thought a smaller simpler patch would be easier to get into linux as
standard would be easier to accept - and that in combination with our
userland tools solves our problem. Also the new version of the patch
which I will write will not completely break the semantics of setgroups
which is what the 2.6.x kernel does now.
As an aside Frank - can you point at a paper which provides a
walkthrough of how your patch works and what the caveats are?
I tried to find a straightforward explanation a while ago and couldn't
- and didn't have the time to work through it myself. I only have a
pretty sketchy understanding of the flow of control/data for nfs/fs
permissions checking in the kernel and it would take me a LONG time to
figure it out - assuming I even could.
For our purposes we would have a single process which needs to be able
to access multiple groups at completely different points in the tree..
For example
/top(0)/p1(2)/p3(2)/p4(2)/p5(6)/file1(6)
/top(0)/p1(2)/p3(2)/p4(2)/p6(7)/file2(7)
/top(0)/p1(2)/p3(2)/p4(2)/p7(8)/file3(6)
/top(0)/p1(2)/p3(2)/p4(2)/p7(8)/file4(8)
And so on - where the (n) indicated the (gid) for that directory/file.
So most of our directories are in the same group. But as you get further
down the tree the groups start to change.
The process will belong to > 16 groups.
Thanx
Bill
Frank van Maarseveen wrote:
> On Tue, Jul 11, 2006 at 04:26:48PM +1200, Bill Ryder wrote:
>
>> Hello all,
>>
>> Setting the kernel config option of UNSORTED_SUPPLEMENTAL_GROUPLIST
>> will allow the use of setgroups(2) to reorder a supplemental
>> group list to work around the NFS AUTH_UNIX 16 group limit.
>>
>
> FYI,
>
> This problem has been worked around for several years now using
> these 2.4.x and 2.6.x patches:
>
> http://www.frankvm.com/nfs-ngroups/
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]