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

[Rob Ross]

Gotcha. Seems like we're all getting back on the same page. -- Rob

On Jun 25, 2009, at 10:55 AM, Walter Ligon wrote:

> Yes, that is basically what I was saying.
>
> And you got me there - I do.  I just get nervous when they are 1000  
> miles away and hacking indiscriminately.  Those two are pretty  
> creative so I like to make sure we're on track.  I'm sure this  
> lively discussion is just that - a sign of a good thing!  :)
>
> Rob Ross wrote:
>> 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