On Fri, 13 Feb 2015, Sage Weil wrote: > Got this from JJ: > > > The SA expanded on this by stating that there are basically three main > > scenarios here: > > > > 1) We trust the UID/GID in a controlled environment. In which case we > > can safely rely on the POSIX permissions. As long as root_squash is > > available this would be fine. > > I think adding a root_squash option to client/Client.cc and the ceph.ko > should be pretty easy... Er, this is a server option, actually. It'd go in the MDSAuthCap probably? > > 2) Multi-tenant systems. In these cases being able to create keyrings > > which limit access to specified directories would be ideal. > > This is mainly enforcing uid/gid and mount path in MDSAuthCap, and not > unlike what we'll need for OpenStack Manila. I think it's something like > > 1- establish mount root inode ref when session is opened/authenticated > 2- verify in reply path that any inode we reference is beneath that point > 3- special case inodes in stray directory, hopefully in some secure-ish > way based on where they lived previously. (not sure how this'll work...) > > > 3) Government and financial sectors, with more sensitive information. In > > these cases the same capabilities as 2 but also the ability to have an > > audit trail of what is accessed, when, and from where. > > This one I'm happy to ignore for now... :) > > sage > > -- > 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 > > -- 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
