On Nov 14, 2013, at 5:37 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: > On Thu, Nov 14, 2013 at 8:21 AM, Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: >> On Thu, Nov 14, 2013 at 4:55 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: >>> Ah, I hadn't gotten that from skimming the blueprint. So this isn't >>> just about hooking into Kerberos when we do a mount, you want to >>> dynamically retrieve different caps from the monitors as users log on, >>> and have that single client choose between them based on who's making >>> the request? >> >> In our proposal the "additional capabilities" (which allow IOs with a >> particular file/object) are encrypted and sent by the MDS to the >> client who passes it on to the OSD for object IOs. > > I'm confused; if two different people are using the same client mount, > the MDS can't distinguish between them unless the client is > cooperating. Isn't that what you were saying it needs to do? It's the "who passes it on" which created the confusion? This was to say that the client kernel module can't decrypt the additional capability (as it does not have the corresponding key). That does however not mean that the MDS or the CephFS client module can't distinguish between users as all communication is done using session keys. That's at least how I understood it :) >>>>> the MDS tickets in a lot more detail than you have there, though — for >>>>> instance, with your current description you'll need a shared secret >>>>> between the OSD and MDS, and you'll need to expire the client extra >>>> >>>> Right, the shared secret is the kerberos service key in our model. >>> >>> So the whole Ceph cluster has one shared service key, and they use >>> that for securing everything that anybody does? (Sorry, that's >>> probably an elementary question, but I haven't looked at Kerberos >>> since Yehuda implemented the initial CephX auth.) >> >> We've used the shared service key in the past with other distributed >> file systems. But perhaps the model can be changed to per-OSD/MDS >> keys. >> >>> By the time I arrived this was all history; you'll have to wait until >>> Sage gets back for that one. I suspect he didn't like the performance >>> enough and the trees had diverged non-trivially by the time Maat was >>> in a useful state. But if you are brave, you can go back in time >>> (couple years ago) and look for the "security" folder, which I think >>> contained the Maat changes, and see what would be involved in >>> extracting them. :) >> >> Is it this one? >> https://github.com/ceph/ceph/tree/historic/aleung_mds_security/ > > Specifically the branches/aleung/security1/ folder in there. (This is > all svn branches converted to a git repository, etc, so the > organization is a bit weird.) Cheers, Arne -- 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
