[Pvfs2-developers] sgids

[Sam Lang]

Hi All,

A while back there was a discussion about secondary group ids, and  
how PVFS does permissions checking on the server.  Currently in the  
trunk, the PVFS server checks the gid against the secondary ids on  
the server for the associated uid.  This is problematic if the server  
is setup with only a root account, and the user accounts are matched  
with what's on the client nodes (with NIS or something).  The general  
consensus was that  admins shouldn't be required to match users and  
groups between client and server, just between clients that mount the  
same volume, and that the secondary group ids should be sent along as  
part of the credential in our requests.  The attached patch does this.

The basic codepath for sending the secondary ids to the server is as  
follows.  The PVFS_credentials struct now holds an array of PVFS_gid  
for the secondary group ids.  In the kernel, the gen_credentials code  
fills in the secondary group ids using a cred mem cache for the  
default case of at most 32 entries.  If a user has more than 32  
secondary groups, the code switches to using kmalloc.  The credential  
is written as part of the upcall in the request as it did before, but  
the upcall now includes a sgids_count that is sent.  If the  
sgids_count is nonzero, the client does a second read for the  
secondary gids (and the op-specific trailer if one exists).  The  
credential is then serialized with the secondary ids that exist, and  
sent to the server, which checks them if the other permissions checks  
fail.

Some notes on the changes I made:

* PVFS_util_gen_credentials allocates space for the cred, which gets  
freed in PVFS_util_release_credentials.  It returns int instead of  
void.  This call is part of our utils interface, and so its an  
interface change that will break builds for 3rd party users of the  
system interfaces (such as ad_pvfs2).

* I wasn't sure how to handle the serialization of the  
PVFS_credential with the secondary group ids, since there are a  
variable number of them.  The primary issue is the serialized buffer  
size that gets allocated at startup for the different operations.  I  
just specified a max sgid count of 40 for now.  If the user tries to  
send more than that, the encoding fails.  Incidentally, we do the  
same thing with the Request for IO.  The maximum number of nested  
PINT_Requests is set to 100.  Is this something we need to fix?

* I made some changes to reading and writing the request and response  
over the device.  I needed to handle cases where sometimes there were  
secondary group ids, sometimes there was an op-specific trailer,  
sometimes both, sometimes neither.  There's still only at most two  
reads for each request, but I needed to cleanup and modify the state  
management code in order to add bits for the sgids.  I created a dev  
header struct for all the proto/magic/tag bits that we sent  
independently before.  For the upcall on the client, I removed a lot  
of the allocation that was being done.  Now the unexpected info  
struct holds a single buffer for the entire request read off the  
device, and points at different offsets for different parts of the  
upcall.  I also did cleanup in the downcall code for readability.

This is the first significant change I've made to some of the kernel  
module code, so I realize and expect there to be concerns with the  
way I've done things.  Go ahead and be brutal with your criticisms.

Thanks,

-sam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sgids.patch
Type: application/octet-stream
Size: 276475 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20070220/615d41c7/sgids-0001.obj
-------------- next part --------------