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
