[Pvfs2-developers] Batch create in sys-symlink.sm

[Walter Ligon]

The short version goes like this - every request has a signed capability 
included with it that states the request is authorized.  The capability 
is created by one of the servers, which we trust.  We don't need to know 
the source of any given message because we can verify the source of the 
capability.

Now, as Rob surmised, the server that creates the capability normally 
checks whatever permission is involved before creating it.  In the case 
of creating an object, this is generally inherent in the permissions on 
the directory in which the final file (dir, symlink, etc.) is going to 
be placed.

If the creation of files and such are moved to a server, then the 
create-file request would normally include the handle of the parent 
directory, on which permissions can be checked.  The server-to-server 
request to to create datafile objects and so on can be authorized by the 
server doing the create.  Normal users can be prevented from running 
such a request by simply never giving them a capability for that request.

I think the problem comes that where we used to have a request that 
created one object, we now have a request that creates many objects, and 
the current capability can limit which request you run, but not the 
arguments to it, so a capability that allow you to create 1 allows you 
to create many.  If this request is only used server-to-server, the we 
need not ever give a client a capability to use it, but if we want to 
let a client run this request, we either have to risk a malicious user 
chewing through handles, or we have to modify the capabilities to be 
more flexible.

So one solution is to never allow clients to just create and object, 
moving all creation routines to the servers.  Another solution is to 
have two requests a single create request and a bulk-create request and 
only every allow clients to run the single.  Still another is to modify 
the create capability to specify how many objects can be created.

Oddly enough, the last might be the best approach - especially if we 
find that this is the only case where we need to do that, and the only 
options we need are 1 and many.  In this case it becomes pretty easy.

Finally I might also point out that David and Nick did not consult with 
me before deciding how to deal with this.  I guess they figure they 
don't need me any more.

Walt

Sam Lang wrote:
> 
> On Jun 24, 2009, at 3:55 PM, Sam Lang wrote:
>>
>> It sounds like your approach to eliminating security holes is with 
>> "security by obscurity".  In other words, if the client (or some rogue 
>> process acting as a client) does not know that the interface is there, 
>> he can't abuse it.  I don't think that's the right approach, 
>> especially since PVFS is completely open source, and anyone can just 
>> look at the code.
> 
> Rob points out that I don't really know about your security approach, so 
> my above comments may not be entirely appropriate.  I guess what I was 
> trying to say is that it wasn't clear to me from a security perspective 
> that moving batch_create to the server would be helpful for you.  I'd be 
> interested to hear about your security approach though, and will refrain 
> from making comments about it until I have a better understanding of 
> it.  :-)
> 
> In a different context, Phil and I have discussed the issue of the 
> server knowing the source of a request.  It turns out this isn't an easy 
> thing to do, at least for BMI tcp.  Phil has added some code to BMI tcp 
> in a separate branch that provides the functionality internally in BMI, 
> and it shouldn't be hard to export the info through a get_info call.  
> Let us know if that's something you're interested in!
> 
> -sam
> 
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers