2.6.21 strange optimization in svcauth_unix.c

2.6.21 strange optimization in svcauth_unix.c

[Frank van Maarseveen]

While reading the 2.6.21 version of net/sunrpc/svcauth_unix.c it looks
to me that it tries to cache the AUTH_UNIX/AUTH_SYS group list on uid
basis and thus deliberately ignore the group ids supplied by the NFS
client. Fragment of svcauth_unix_accept():

	cred->cr_uid = svc_getnl(argv);		/* uid */
	cred->cr_gid = svc_getnl(argv);		/* gid */
	slen = svc_getnl(argv);			/* gids length */
	if (slen > 16 || (len -= (slen + 2)*4) < 0)
		goto badcred;
=>	if (unix_gid_find(cred->cr_uid, &cred->cr_group_info, rqstp)
	    == -EAGAIN)
		return SVC_DROP;
=>	if (cred->cr_group_info == NULL) {
		cred->cr_group_info = groups_alloc(slen);
		if (cred->cr_group_info == NULL)
			return SVC_DROP;
		for (i = 0; i < slen; i++)
			GROUP_AT(cred->cr_group_info, i) = svc_getnl(argv);
=>	} else {
=>		for (i = 0; i < slen ; i++)
=>			svc_getnl(argv);
=>	}

I guess this caching will break the linux NFS client patch for bypassing
the 16 groups limits maintained by me (http://www.frankvm.com/nfs-ngroups/ )
because in order to bypass the group limitation the group list is
determined dynamically at the NFS client.

Of course I can just disable the above optimization in my own patch but
I wonder what its real purpose is. I don't see a big win so is it an
optimization or is there another reason?

-- 
Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.6.21 strange optimization in svcauth_unix.c

[Neil Brown]

On Friday April 27, frankvm@frankvm.com wrote:
> While reading the 2.6.21 version of net/sunrpc/svcauth_unix.c it looks
> to me that it tries to cache the AUTH_UNIX/AUTH_SYS group list on uid
> basis and thus deliberately ignore the group ids supplied by the NFS
> client.

It is configurable by a switch to mountd, and defaults to 'off'.

When a request arrives, the kernel tries to ask mountd to map the uid
to a list of gids.  If mountd says "no", the kernel uses whatever was
in the RPC request.  If mountd says "yes", the kernel uses the group
list that mountd provided.  mountd can provide a full list of gids,
not just the first 16.

So it is really an alternate to hacking the NFS client.  If you have a
new kernel and new nfs-utils and run mountd with "-g", you don't need
your changes to the NFS client.

I think that it is extremely uncommon to have a different group list
on the client than on the server, so doing the uid -> grouplist
mapping on the server shouldn't cause any surprises.
Note that this scheme leaves the primary groupid unchanged, so a
"newgrp" on the client will still work as expected.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.6.21 strange optimization in svcauth_unix.c

[Frank van Maarseveen]

On Sat, Apr 28, 2007 at 07:27:25PM +1000, Neil Brown wrote:
> On Friday April 27, frankvm@frankvm.com wrote:
> > While reading the 2.6.21 version of net/sunrpc/svcauth_unix.c it looks
> > to me that it tries to cache the AUTH_UNIX/AUTH_SYS group list on uid
> > basis and thus deliberately ignore the group ids supplied by the NFS
> > client.
> 
> It is configurable by a switch to mountd, and defaults to 'off'.
> 
> When a request arrives, the kernel tries to ask mountd to map the uid
> to a list of gids.  If mountd says "no", the kernel uses whatever was
> in the RPC request.  If mountd says "yes", the kernel uses the group
> list that mountd provided.  mountd can provide a full list of gids,
> not just the first 16.
> 
> So it is really an alternate to hacking the NFS client.  If you have a
> new kernel and new nfs-utils and run mountd with "-g", you don't need
> your changes to the NFS client.

Thanks for the explanation. It probably wouldn't work in my case
because the secondary group list is set by a setuid root wrapper
around /bin/sh depending on the project one wants to work on. This
allows delegating access control to people without having to
hand out root passwords (it's more complicated but basically this
describes it).

When mountd can do a callout to a program supplying both uid and gid
to obtain the secondary group list then it could be a replacement
for the client side patch for me. It will never be a replacement
for non-linux NFS servers though. Maybe I'll replace the client
side patch by a (smaller) server side patch if that one is easier
to maintain.

I have given up all hope long time ago to get my client side
patch merged.

-- 
Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs