Gotcha. Seems like we're all getting back on the same page. -- Rob
On Jun 25, 2009, at 10:55 AM, Walter Ligon wrote:
Yes, that is basically what I was saying.
And you got me there - I do. I just get nervous when they are 1000
miles away and hacking indiscriminately. Those two are pretty
creative so I like to make sure we're on track. I'm sure this
lively discussion is just that - a sign of a good thing! :)
Rob Ross wrote:
Hi Walt,
Thanks for the explanation. So to make sure I understand how one
would differentiate between servers and clients (if that is
importatn), basically servers would never hand out a capability
allowing someone to perform an operation we didn't want clients to
perform (e.g., a batch create, if that's the solution chosen). Then
only servers could perform the operation, because they can create a
capability for themselves that allows them to do the operation
(because they are trusted). Right?
I thought you liked it when the students ran off and started
hacking on their own :)? Or did you get tired of that after a
while :)?
Rob
On Jun 25, 2009, at 12:33 AM, Walter Ligon wrote:
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
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
