Hi Alex, The problem is that the cephx keyring would still be needed on untrusted hosts. With that, anyone can delete/corrupt the underlying objects (though they may be encrypted) using rados. Cheers, Dan On Thu, Nov 14, 2013 at 9:09 PM, Alex Elsayed <eternaleye@xxxxxxxxx> wrote: > Dan van der Ster wrote: > >> Hi Greg, > <snip> >> AFAICT, this would allow single users to mount a subtree on CephFS and >> prevent them from writing where they are not permitted. But our >> use-case is different: we want to mount /cephfs/ from shared >> workstations and batch nodes to store personal home directories, >> shared group areas, and read-only software areas. Managing per-user >> keyrings and per-user mountpoints would become quickly unmanageable. > <snip> > > Actually, there are a number of ways this could be managed pretty reasonably > - eCryptfs, in particular, may be worth examining. It ships with a > pam_ecryptfs module that (on login) uses the login password to produce the > decryption key, and load it into the user's session keyring (which is then > associated with every process in that session, although I don't think > eCryptfs uses that). It then mounts the eCryptfs filesystem, and the kernel > uses the loaded key for decryption. > > If the credentials are only used on mount, something similar to pam_ecryptfs > could work, or a minimal module that _only_ loads the key followed by > pam_mount. > > If the credentials are handled on FS operations, then you'd be able to have > a single top-level mount with minimal privileges and then use the kernel > keyring on access. > > That also opens up using 'keyctl' to manually load the key into the user or > session keyring, or using trusted/encrypted keys to allow secure automated > mounts. > > In fact, trusted or encrypted keys could be very useful if someone wanted to > securely use Ceph as a rootfs - they'd make it possible to authenticate > mounts based on the hardware, not just the configuration. > > -- > 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
