> On Nov 20,  3:02am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> -- Subject: Re: crcmp(), once again
>
> | > >> Please explain why the order of groups is important. I
> don't see it.
> | > >
> | > >When it has to be shortened because the NFS packets only have space
> | > >for a small number of groups....
> | >
> | > In that case instead of truncating the group list one should check
> | > which groups are irrelevant to the operation and get rid of those.
> | >
> | > christos
> |
> | i don't think it's worth to break existing systems in this case.
>
> Can you please explain to me how does this break existing systems? If I am
> in many groups and I try to modify a file that belongs to a group
> that will
> be truncated I will get `Permission Denied'. If, on the other
> hand, I choose
> to include the group relevant to the operation and not another group
> that is not used in the current RPC operation, how does that break things?

It is unreliable for the NFS client to guess what group(s)
will be relevant for access control on the NFS server.
In NFSv2 clients tried to guess (interpret access control --
mode bits, owner uid and gid) and that didn't work
very well in many circumstances. NFSv3 added the ACCESS
operation so that the server could be consulted and
the real answer obtained.

The limit of 16 groups is well known and, in my experience,
admins try not to exceed it when NFS is heavily used.

I think it makes sense to think of the credential gids[]
as an unordered list. I'm not sure how crcmp() would ever
encounter equivalent credentials with gids[] in a different
order, but it is possible. I'm also not sure how an admin
would influence which are the first 16 gids[] in a credential
for NFS reasons, but I suppose that's possible too.

I don't remember what started this thread. On the face
of it, memcmp() to compare credentials seems wrong. But
I've enjoyed monitoring to see what practical problems
pop up if doing a more intelligent crcmp().

Regards,
	-gww