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

[Walter Ligon]

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