Re: CDS blueprint: strong auth for cephfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux