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

sure.
there are no reliable way for client to know which group is
relevant to an operation.  it's up to administrators.

(well, as netbsd's local NGROUPS "happens to" be also 16, you need to have
mount_nfs -g to trigger the incompatibility.  but it's merely a detail.)

> I think it makes sense to think of the credential gids[]
> as an unordered list.

as far as we have a filesystem which cares the order,
i don't think it's reasonable to think it unordered.

even if it's desirable to make crcmp ignore the order,
sorting in setgroups doesn't help it at all.

> I'm not sure how crcmp() would ever
> encounter equivalent credentials with gids[] in a different
> order, but it is possible.

it's easy to make the case as the list is come from /etc/exports.

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

an easy way is to modify the order in /etc/groups.

YAMAMOTO Takashi