Walt - Thanks for clearing everything up. For some reason I was having a lot of trouble trying to explain how we were using capabilities.
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. 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. Nick On Thu, Jun 25, 2009 at 7:48 AM, Rob Ross <rr...@mcs.anl.gov> 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 >>> Pvfs2-developers@beowulf-underground.org >>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers >>> >> _______________________________________________ >> Pvfs2-developers mailing list >> Pvfs2-developers@beowulf-underground.org >> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers >> > >
_______________________________________________ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
