Project

General

Profile

Feature #16656

mount.ceph: enable consumption of ceph keyring files

Added by John Spray over 3 years ago. Updated about 2 months ago.

Status:
Pending Backport
Priority:
High
Assignee:
Category:
Administration/Usability
Target version:
Start date:
Due date:
% Done:

0%

Source:
Development
Tags:
Backport:
nautilus
Reviewed:
Affected Versions:
Component(FS):
kceph
Labels (FS):
Pull request ID:

Description

Jeff pointed this out in doc review:

we really ought to fix up the mount helper to use the same sort of keyring file as the fuse client. While it's not hard to strip out the secret from the keyring file, it's not obvious and is somewhat "fiddly".


Related issues

Related to fs - Bug #41892: qa: convert kcephfs qa tests to use mount.ceph auto-discovery features Resolved
Copied to fs - Backport #41890: nautilus: mount.ceph: enable consumption of ceph keyring files In Progress

History

#1 Updated by Jeff Layton over 3 years ago

  • Assignee set to Jeff Layton

I'll go ahead and grab this one. Not a high priority but definitely a nice-to-have from a usability perspective.

#2 Updated by Greg Farnum over 3 years ago

  • Category set to Administration/Usability

#3 Updated by Patrick Donnelly 8 months ago

  • Assignee deleted (Jeff Layton)

#4 Updated by Jeff Layton 3 months ago

  • Assignee set to Jeff Layton

#5 Updated by Patrick Donnelly 3 months ago

  • Subject changed from Enable mount.ceph to consume ceph keyring files to mount.ceph: enable consumption of ceph keyring files
  • Status changed from New to In Progress
  • Priority changed from Normal to High
  • Target version set to v15.0.0
  • Start date deleted (07/12/2016)
  • Source changed from other to Development
  • Backport set to nautilus
  • Component(FS) kceph added

#6 Updated by Jeff Layton 3 months ago

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.

#7 Updated by Patrick Donnelly 3 months ago

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?

#8 Updated by Jeff Layton 3 months ago

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.

#9 Updated by Patrick Donnelly 3 months ago

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.

#10 Updated by Patrick Donnelly 3 months ago

  • Status changed from In Progress to Need Review
  • Pull request ID set to 29642

#11 Updated by Jeff Layton 3 months ago

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.

#12 Updated by Jeff Layton 3 months ago

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.

#13 Updated by Patrick Donnelly about 2 months ago

  • Status changed from Need Review to Pending Backport

#14 Updated by Nathan Cutler about 2 months ago

  • Copied to Backport #41890: nautilus: mount.ceph: enable consumption of ceph keyring files added

#15 Updated by Patrick Donnelly about 2 months ago

  • Related to Bug #41892: qa: convert kcephfs qa tests to use mount.ceph auto-discovery features added

#16 Updated by Nathan Cutler about 2 months ago

  • Pull request ID changed from 29642 to 29817

Also available in: Atom PDF