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... > 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
