Ok, I've gone ahead and coded my "middle ground" solution to our little batch create issue. Let me know what you think:<br><br><span style="font-family: courier new,monospace;">static int perm_batch_create(PINT_server_op *s_op)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">{</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> int ret;</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> if (s_op->req->capability.op_mask & PINT_CAP_BATCH_CREATE)</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> {</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> ret = 0;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> }</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> else if ((s_op->req->capability.op_mask & PINT_CAP_CREATE) &&</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> (s_op->req->u.batch_create.object_count == 1))</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> {</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> /* create capability allows you to create only one object */</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> ret = 0;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> }</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> else</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> {</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> ret = -PVFS_EACCES;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> }</span><br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> return ret;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">}</span><br><br><font face="arial,helvetica,sans-serif">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.<br>
<br>I intend for only servers to be given the batch create capability at this point.<br><br>Nick<br></font><br><div class="gmail_quote">On Thu, Jun 25, 2009 at 10:37 AM, Rob Ross <span dir="ltr"><<a href="mailto:rross@mcs.anl.gov">rross@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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?<br>
<font color="#888888">
<br>
Rob</font><div><div></div><div class="h5"><br>
<br>
On Jun 25, 2009, at 11:04 AM, Walter Ligon wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
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.<br>
<br>
Walt<br>
<br>
Rob Ross wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Jun 25, 2009, at 9:45 AM, Nicholas Mills wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Rob -<br>
<br>
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.<br>
<br>
Everyone -<br>
<br>
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.<br>
</blockquote>
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.<br>
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...<br>
Ok, so all that leads me to agree that you don't ideally want clients to be given permission to use this operation :).<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
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?<br>
Rob<br>
</blockquote></blockquote>
<br>
</div></div></blockquote></div><br>