2.6.21 strange optimization in svcauth_unix.c
Subsystems (2)
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?
Signature · 10 lines
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 - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 4 lines · On Friday April 27, [email protected] wrote:
While reading the 2.6.21 version of
net/sunrpc/svcauth_unix.cit 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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 14 lines · Neil Brown
Quoted 4 lines · On Friday April 27, [email protected] wrote:
While reading the 2.6.21 version of
net/sunrpc/svcauth_unix.cit 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.
Quoted 3 lines
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.
Signature · 10 lines
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 - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs