On Mon, Jun 1, 2015 at 12:39 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > I have a pull request posted at > > https://github.com/ceph/ceph/pull/4809 > > that updates the mds cap parser and defines a check method. Please take > a look and see if this makes sense. Couple comments on the internal interfaces but the syntax seems good and so do the MDSCap changes. > > For the path restrictions, I think the next steps are something like > > - generate a path string and pass it in to that method > - write some simple tests > - make sure the hook is called from everywhere it needs to be (all of the > other request handlers in Server.cc) > - call the hook from the cap writeback path (tricky) > - figure out how to handle files in the stray dir (tricky) This path access function was my concern (we need to push that down inside of the MDSCaps rather than exposing their internal state); making that change will probably impact how we do these. But this general set of tasks seems right to me. Probably we do unit tests first, which we can do once it's all MDSCap internal. ;) I'm not sure if including the inode is actually going to be helpful to us? We can't use it instead of the path, for instance. Users might have access via one path but not another and we need to check both that they can reach the inode and that they came in the right way. > For the user-based restrictions, > > - I think we need to expand the allows() method so that it has a couple > output arguments (uid and gid list) that subsequent permissions should be > validated against. Then we can change the function in Server.cc so > that when those are populated it does an actually unix permissions check. > This seems like the simplest thing to me, although it does have the > slightly-odd property that if you are doing an operation that requires > permission on two inodes (directory and file, say) you might have to > different 'allow ...' lines granting access to each. (I think this is > both painful to avoid and also harmless?) Why don't we just pass in the UID and GID the request is being made as? Then it's either allowed or denied. -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
