On Fri, Feb 13, 2015 at 5:05 AM, Sage Weil <sweil@xxxxxxxxxx> 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... > >> 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...) This concerns me: 1) We have nothing to control access to raw objects, so there is some security against accidents here, but not against malicious code users. 2) Path verification is going to be tricky to handle with symlinks and things. Moving it into the reply path as you discuss makes one set of decisions on that (I'm not sure how flexibly?) 3) Cleanup in the case of failed requests would be pretty difficult — we don't want to take away caps from other clients if the permissions check failed, we have to "disappear" any which we were planning to give out with the denied request, etc. And much of that work (eg the cap revocation) happens well before the client gets any kind of reply, for instance gathering data for stats. :( That doesn't make any of these problems intractable, but I don't think it's going to be a quick patch series and it will require a lot of testing with new mechanisms that don't exist yet. -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
