Re: CDS blueprint: strong auth for cephfs

[Alex Elsayed <eternaleye@gmail.com>]

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.