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