On Thu, May 28, 2015 at 11:02 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: >> > The MDS could combine a tenant ID and a UID/GID to store unique >> > UID/GIDs on the back end and just strip off the tenant ID when >> > presented to the client so there are no collisions of UID/GIDs between >> > tenants in the MDS. >> >> Hmm, that is another thought... > > Unless you ask Ceph to enforce the unix permissions server side, the > uid/gid are stored but not interpreted. I don't think the tenant ID is > needed since there is no impact if the same uids are used in different > subtrees. It's just up to the admin to divvy up non-overlapping subtrees > to the tenants... I don't think I would expect Ceph to enforce file permissions, only share permissions. The file permissions should be enforced by the host mounting the FS. If Ceph appends 8 bits as the Tenant ID to the 16 bit UID/GID for example, then Ceph only has to match and act the first 8 bits and pass the next 16 bits to the client. It only has to store the UID/GID and perms/ACLs. Then you don't have to worry about not crossing the streams in subtrees. If an admin later decides to provide access to two clients to the same subtree nothing bad will happen. The two clients will have to figure out between themselves what to do with UID/GIDs/perms/ACLs to provide the appropriate access. If for instance a directory is shared between tenant A and B, and A can write and B can't, then when B tries to write because the perms are correct for the UID/GID on the client side, the MDS will prevent the write because that tenant doesn't have "share" write access on that directory. If a tenant wants to allow write access to part of a directory, then there has to be some level of trust that they will act responsibly. I can't see getting around that without implementing Kerberos and preventing the client from mapping to other UID/GIDs, but that really takes the flexibility out of the system. ---------------- Robert LeBlanc GPG Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 -- 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
