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

[Rob Ross]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20090625/1ea6e01b/attachment.htm