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
