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

[Rob Ross]

Hi Walt,

Thanks for the explanation. So to make sure I understand how one would  
differentiate between servers and clients (if that is importatn),  
basically servers would never hand out a capability allowing someone  
to perform an operation we didn't want clients to perform (e.g., a  
batch create, if that's the solution chosen). Then only servers could  
perform the operation, because they can create a capability for  
themselves that allows them to do the operation (because they are  
trusted). Right?

I thought you liked it when the students ran off and started hacking  
on their own :)? Or did you get tired of that after a while :)?

Rob

On Jun 25, 2009, at 12:33 AM, Walter Ligon wrote:

> 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
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers