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

[Rob Ross]

Great thanks for the clarification.

-- Rob

On Jun 25, 2009, at 3:31 PM, Nicholas Mills <nlmills at g.clemson.edu>  
wrote:

> That's correct. If they need the batch create capability they just  
> make one right before the request is sent out.
>
> On Thu, Jun 25, 2009 at 2:30 PM, Rob Ross <rross at mcs.anl.gov> wrote:
> Just to make sure that I understand, servers aren't requesting  
> capabilities from anyone, right? They just grant themselves batch  
> create permission if they need it?
>
> -- Rob
>
> On Jun 25, 2009, at 3:20 PM, Nicholas Mills <nlmills at g.clemson.edu>  
> wrote:
>
>> Ok, I've gone ahead and coded my "middle ground" solution to our  
>> little batch create issue. Let me know what you think:
>>
>> static int perm_batch_create(PINT_server_op *s_op)
>> {
>>     int ret;
>>
>>     if (s_op->req->capability.op_mask & PINT_CAP_BATCH_CREATE)
>>     {
>>         ret = 0;
>>     }
>>     else if ((s_op->req->capability.op_mask & PINT_CAP_CREATE) &&
>>              (s_op->req->u.batch_create.object_count == 1))
>>     {
>>         /* create capability allows you to create only one object */
>>         ret = 0;
>>     }
>>     else
>>     {
>>         ret = -PVFS_EACCES;
>>     }
>>
>>     return ret;
>> }
>>
>> This code says that if the request has the "batch create"  
>> capability then allow the operation to complete. If the request  
>> only has the "create" capability but the size is one (like in a  
>> normal create) then go ahead and allow it. Otherwise, access is  
>> denied.
>>
>> I intend for only servers to be given the batch create capability  
>> at this point.
>>
>> Nick
>>
>> On Thu, Jun 25, 2009 at 10:37 AM, Rob Ross <rross at mcs.anl.gov> wrote:
>> I'm not sure how important the bulk-create issue is either, but I  
>> thought I'd bring up the file creation as a related place where a  
>> malicious user could consume lots of resources quickly. Seems like  
>> if we're going to try to address one then we need to try to address  
>> the other?
>>
>> Rob
>>
>>
>> On Jun 25, 2009, at 11:04 AM, Walter Ligon wrote:
>>
>> up until now it has been the user's prerogative to create files  
>> with as many dfiles as he wants - I assume a user is limited to  
>> some max by the configuration (is he?) but that could be large - so  
>> he could allocate 100 dfiles and only use 2 (if he only uses 1 the  
>> stuffing will come into play).  I'm open to discussion of how to  
>> deal with that in terms of interface and such.  If we need that we  
>> can work on a way to do it.
>>
>> Over the last year I've found David & Nick to be very thorough in  
>> trying to design so that users can only do what they are supposed  
>> to do.  It may be that it really isn't that bid a deal if users can  
>> allocate extra object - as long as they can't link anything to  
>> them.  I fully suspect that we can improve beyond the basic level  
>> of security we are working on now and we can discuss that.  What  
>> I'm saying is I'm not sure how important this bulk-create issue  
>> really is - but there are ways to deal with it.
>>
>> Walt
>>
>> Rob Ross wrote:
>> On Jun 25, 2009, at 9:45 AM, Nicholas Mills wrote:
>> Rob -
>>
>> You're absolutely correct. The capabilities are trusted and can  
>> only come from servers. If a client gets a hold of one it's assumed  
>> that some server determined the client had a need for the  
>> capability. Servers are able to create capabilities for themselves  
>> that allow them to do anything.
>>
>> Everyone -
>>
>> Right now I haven't had a need to differentiate between client and  
>> server requests. However, in the case of batch create I'd really  
>> like to prevent a client from having access to this capability. For  
>> the moment the only client state machine to use batch create is sys- 
>> symlink, and even then the state machine only creates one handle.
>> Walt suggested perhaps limiting clients to a single create by use  
>> of some sort of differentiator in the capability. This would avoid  
>> the need to change how PVFS is working today, but means you'd have  
>> to do a little parameter checking; how awkward would that be? Seems  
>> to me you might want to similarly be restricting the *types* of  
>> objects that a client could create, if you're going to try to  
>> minimize the potential damage from this particular call. Since  
>> clients would only be using this to create a symlink object (if I  
>> understand the earlier discussion correctly), you could limit  
>> clients to only creating symlink objects and only one at a time.
>> Otherwise a client might be able to use this facility to create a  
>> metadata object, populate it with something that makes it look like  
>> it should have permission to access the associated datafiles, and  
>> then point at some datafiles it would like to access? I dunno the  
>> bigger picture, so I don't know if you have already handled this  
>> possibility in some other way...
>> Ok, so all that leads me to agree that you don't ideally want  
>> clients to be given permission to use this operation :).
>> Above all I want everyone to know that I'm very open to suggestion.  
>> Of course I realize that in the future new client state machines  
>> could make use of the batch create request. But for now, at least,  
>> only the servers have a legitimate need for this request.
>> Now that I'm looking at this, why aren't you equally worried about  
>> a user using the new create request and specifying some  
>> ridiculously large num_dfiles_req? Doesn't that have the same  
>> problem with respect to resource consumption?
>> Rob
>>
>>
>
> _______________________________________________
> Pvfs2-developers mailing list
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20090625/ec61917b/attachment.htm