Message-ID: <44BFEA4C.6050602@wetafx.co.nz>
Date:	Fri, 21 Jul 2006 08:40:44 +1200
From:	Bill Ryder <bryder@...afx.co.nz>
To:	Frank van Maarseveen <frankvm@...nkvm.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.18-rc1]  Make group sorting optional in the 2.6.x
 kernels

First of all a reminder.

We have proprietary UNIX here.

All I need from linux is that it obeys the setgroups(2) POSIX call - at
least  in the first 16 groups.


Frank van Maarseveen wrote:
> On Thu, Jul 20, 2006 at 08:17:47AM +1200, Bill Ryder wrote: [...]
>> As an aside Frank - can you point at a paper which provides a
>> walkthrough of how your patch  works and what the caveats are?
>
> http://www.frankvm.com/nfs-ngroups/README

I  read that when I was first researching this. But I couldn't see how
it works based on the description. Bearing in mind I do not spend hours
understanding how the kernel walks permissions and paths.

By walkthrough I mean a walkthrough of permissions checking for the
paths I outlined below. The test case being where every file is in a
different group (and of course the groups are outside fo the first 16
groups in the grouplist). You can not assume their parent directory
belongs to the same group as the file.

This isn't a walkthrough:

<quote>

It is fairly simple to predict the group id's which might make a difference
in an operation on NFS on the client system, assuming the NFS server does
permission checking conform UNIX. This is not a bad assumption when NFS
uses RPC with AUTH_UNIX authentication. Pathnames at system call time
are not handled in one NFS operation (NFS != WebNFS) but by a series
of NFS lookups. Therefor the maximum number of groups required at any
specific point in time is 3 at most: see nfs_rename().

</quote>

Nor is this:

<quote>
Patch 4.x

Group id cache is gone. At the top NFS layer the group ids of
"interesting" file-system objects are collected (max 3, mostly 1) and
passed downwards. When an RPC credential is created the new AUTH_UNIX
specific unx_add_groups() function will add all the necessary group
information. When the number of groups is 16 or lower then it reverts
to old behavior. When there is no group id information passed downwards
then it reverts to old behavior too. Otherwise, only groups present in
_both_ group information passed downwards and the secondary group list
will be used for the AUTH_UNIX rpc credential (i.e. group lists are
intersected).
</quote>

There are a number of  'assumptions' that I do not have the knowledge to
know if they are reasonable or not.

This phrase is worrying:

When there is no group id information passed downwards
then it reverts to old behavior too.

Why would no group id information be passed?

For someone of my level of knowledge of the kernel the README does not
convince me it will work in all situations. One of my colleagues coined
the phrase  "You can't predict the worse case at Weta DIgital". This is
definitely a true statement for us!

In other words the README assumes a lot of implied knowledge which I
don't have. Hence I don't understand why it doesn't work in the above
case. Which is why I asked for a presentation/paper which would
walkthrough the case below (extending it to > 16 groups of course).


But I will say again just to be sure you understand it's not your patch
that is the problem (or the solution). I need a solution that will work
with *nixs for which I do not have kernel source.

The 'right' way to do this is to use posix calls and/or provides OS
calls to solve the problem in a transparent easy to explain and
understand way to all levels of reasonable IT people.

>
>> 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.
>
> setgroups() require privilege. I don't understand how the above is
> supposed to work for non-root users needing >16 groups. And when
> you're root it is silly to play these group games for getting access.
>

It's no sillier than sg or SCO's sgs. There are clearly defined posix
ways to get this information and to use it. OSx of course has a slightly
different way to handle > 16 groups but it still is sensible and
setgroups still works.

I need to solve the problem of NFS only allowing 16 groups when we have
around 32 groups here.

It needs to work on multiple OSs. At the moment Linux is the only OS
this does not work for (unless we stick to 2.4.x kernels - which is not
acceptable).

Any solution needs to use standard methods (ie using APIs shipped with
the box/OS and using a standard kernel - ie not patched).

At the moment linux 2.6.x breaks the semantics of setgroups,  That needs
to be fixed. I will write a patch for that (at least in the first 16
groups)  It will be small and hopefully easy enought to understand so
that it will be a standard part of the kernel.

That way linux will behave in the same way with respect to the first 16
groups as all the other *nixs we run.

---
Bill Ryder
System Engineer
Weta Digital  - land of virtual  hobbits, Gandalf, Big Monkeys, robots,
mutants and anything else you can imagine that can be rendered, shaded,
modelled, animated, motion captured, tracked, simulated, comped or painted.









-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists