You are right. Currently we aren't focusing on resource abuse issues,
but obviously the guys are trying to think ahead, and in doing so should
consider that point.
The only thing I have right now is that we have no way to know if a user
is requesting excess dfiles when creating a file. We do know he doesn't
need them when creating other things. We could implement a set of
attributes that set limits on a user and check those as part of the
process. If we want to do that, then we need to have a serious talk
about how to implement, how to manage it, what people outside would
expect - like should it integrate into existing quota systems, etc. I
see that as a future task at the moment.
Walt
Rob Ross 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@beowulf-underground.org
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
