Ceph » CephFS

My current thinking is to link in libceph-common, create a context and fetch the keys using the same C++ routines that we use in librados/libcephfs, etc. We'll need to copy the key into an allocated buffer, but that should be no big deal.

My main worry is doing all of that in a privileged task. /bin/mount is a setuid program, and this could potentially open a new attack vector if there are buffer overruns or something in these libraries.

One potential way to deal with that would be to have the client fork, drop privileges in the child and do all of the keyring parsing work there. The child would get the secret and pass it back to the parent using MAP_SHARED|MAP_ANONYMOUS memory.

Jeff Layton wrote:

My current thinking is to link in libceph-common, create a context and fetch the keys using the same C++ routines that we use in librados/libcephfs, etc. We'll need to copy the key into an allocated buffer, but that should be no big deal.

My main worry is doing all of that in a privileged task. /bin/mount is a setuid program, and this could potentially open a new attack vector if there are buffer overruns or something in these libraries.

One potential way to deal with that would be to have the client fork, drop privileges in the child and do all of the keyring parsing work there. The child would get the secret and pass it back to the parent using MAP_SHARED|MAP_ANONYMOUS memory.

If you're going to the trouble of forking a child, perhaps we can just fork/execve /usr/bin/ceph and fetch the key that way?

That's certainly another possibility. I'm not sure it's any easier though.

We'd have to scrape and parse the output of the command (which is always complex), and deal with potential changes to the error messages or output format.

I'm going to stick with plan A for now, but I'll keep that scheme in mind if it becomes untenable.

Jeff Layton wrote:

That's certainly another possibility. I'm not sure it's any easier though.

We'd have to scrape and parse the output of the command (which is always complex), and deal with potential changes to the error messages or output format.

We can always make the output simple (possibly with a new sub-command) for the purposes of mount.ceph. With tests, we can catch any regressions.

I'm going to stick with plan A for now, but I'll keep that scheme in mind if it becomes untenable.

ACK, fine with me.

PR here: https://github.com/ceph/ceph/pull/29642

It occurs to me though that now that we have a way to get to the ceph config, we could expand the usage here too. It might be nice to also implement auto-discovery of mon addrs, for instance:

# mount -t ceph foo /mnt/cephfs

...when the mount helper doesn't understand the "device" part, it could search the config for mon addrs, which could then be handed off to the kernel. Potentially we could fetch other settings out of the conf as well.

That said, w could implement this later, after the initial patchset is merged.

Updated PR here:

https://github.com/ceph/ceph/pull/29817

This not only allows the helper to find cephx secrets from keyrings, but also monitor addresses when they aren't specified.