The short version goes like this - every request has a signed capability
included with it that states the request is authorized. The capability
is created by one of the servers, which we trust. We don't need to know
the source of any given message because we can verify the source of the
capability.
Now, as Rob surmised, the server that creates the capability normally
checks whatever permission is involved before creating it. In the case
of creating an object, this is generally inherent in the permissions on
the directory in which the final file (dir, symlink, etc.) is going to
be placed.
If the creation of files and such are moved to a server, then the
create-file request would normally include the handle of the parent
directory, on which permissions can be checked. The server-to-server
request to to create datafile objects and so on can be authorized by the
server doing the create. Normal users can be prevented from running
such a request by simply never giving them a capability for that request.
I think the problem comes that where we used to have a request that
created one object, we now have a request that creates many objects, and
the current capability can limit which request you run, but not the
arguments to it, so a capability that allow you to create 1 allows you
to create many. If this request is only used server-to-server, the we
need not ever give a client a capability to use it, but if we want to
let a client run this request, we either have to risk a malicious user
chewing through handles, or we have to modify the capabilities to be
more flexible.
So one solution is to never allow clients to just create and object,
moving all creation routines to the servers. Another solution is to
have two requests a single create request and a bulk-create request and
only every allow clients to run the single. Still another is to modify
the create capability to specify how many objects can be created.
Oddly enough, the last might be the best approach - especially if we
find that this is the only case where we need to do that, and the only
options we need are 1 and many. In this case it becomes pretty easy.
Finally I might also point out that David and Nick did not consult with
me before deciding how to deal with this. I guess they figure they
don't need me any more.
Walt
Sam Lang wrote:
On Jun 24, 2009, at 3:55 PM, Sam Lang wrote:
It sounds like your approach to eliminating security holes is with
"security by obscurity". In other words, if the client (or some rogue
process acting as a client) does not know that the interface is there,
he can't abuse it. I don't think that's the right approach,
especially since PVFS is completely open source, and anyone can just
look at the code.
Rob points out that I don't really know about your security approach, so
my above comments may not be entirely appropriate. I guess what I was
trying to say is that it wasn't clear to me from a security perspective
that moving batch_create to the server would be helpful for you. I'd be
interested to hear about your security approach though, and will refrain
from making comments about it until I have a better understanding of
it. :-)
In a different context, Phil and I have discussed the issue of the
server knowing the source of a request. It turns out this isn't an easy
thing to do, at least for BMI tcp. Phil has added some code to BMI tcp
in a separate branch that provides the functionality internally in BMI,
and it shouldn't be hard to export the info through a get_info call.
Let us know if that's something you're interested in!
-sam
_______________________________________________
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
