Re: Keys & caps

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

 



Hi,

On Mon, 9 Jul 2012, Székelyi Szabolcs wrote:
> Hello,
> 
> this far I accessed my Ceph (0.48) FS with the client.admin key, but I'd like 
> to change that since I don't want to allow clients to control the cluster.
> 
> I thought I should create a new key, give it some caps (don't exactly know 
> which ones), and distribute it to clients. Here are some things I don't 
> know/understand:
> 
> * What do the r, w, x, and * caps ("permissions"?) mean on a mon, mds, or osd?

They roughly correspond to read, write, execute.  The distinction is 
subtle and poorly specfied for mon caps; just use the documented values 
for now.  For the mds, it's just 'allow', as we haven't properly defined 
those yet either.  The osd ones are the most useful and well defined.  
There is a grammar in osd/OSDCap.h if you can grok the boost::spirit 
syntax.  In addition to rwx, you can grant by pool or object prefix.  
There is some preliminary/incomplete support for fine-grained control over 
the use of rados classes.

> * What's the difference between (for example) 'allow rw' and 'rw' caps? `ceph 
> auth` seems to understand (and display as specified) both forms.

'rw' is nonsense... it needs to be (a list of) 'allow <something>' 
phrase(s).  From the monitor's perspective, the osd and mds caps are 
opaque, so it won't enforce a particular syntax.  At some point we can 
make it verify they parse properly, but that hasn't happened yet.

> Not to run into issues with caps, I've created a key with the same caps as the 
> current client.admin, but with a different key, called client.access_fs. I 
> planned to narrow down the caps after I made the mount work with the new key.
> 
> $ sudo ceph auth list
> installed auth entries: 
> [...]
> client.access_fs
>         key: AQ...==
>         caps: [mds] allow
>         caps: [mon] allow *
>         caps: [osd] allow *
> [...]
> 
> I've copied the key to the client as /etc/ceph/keyring:
> 
> [client.access_fs]
>         key = AQ...==
> 
> I have 'keyring = /etc/ceph/keyring' in my ceph.conf [global] section on the 
> client. Now trying to mount the filesystem fails with
> 
> $ sudo mount /mnt/ceph
> ceph-fuse[1784]: starting ceph client
> ceph-fuse[1784]: ceph mount failed with (1) Operation not permitted
> ceph-fuse[1782]: mount failed: (1) Operation not permitted
> 
> Adding '-o name=client.access_fs' to the command line yields the same result. 
> If I copy the client.admin key into the keyring file, it works. (However, 
> adding the same mount option again (so the name= parameter and the key name in 
> the file do not match), I get an error (which seems okay to me, not sure about 
> the correctness):
> 
> $ sudo mount /cloud/ -o name=client.access_fs
> ceph-fuse[1835]: starting ceph client
> ceph-fuse[1835]: starting fuse
> fuse: unknown option `name=client.access_fs'
> 2012-07-09 16:03:18.343793 7fb0e7b8b780 -1 fuse_lowlevel_new failed
> ceph-fuse[1835]: fuse finished with error 33
> ceph-fuse[1833]: mount failed: (33) Numerical argument out of domain
> 
> Could you clear up the confusion in my head? :)

The problem is that the mount.ceph command doesn't understand keyrings; it 
only understands secret= and secretfile=.  There is a longstanding feature 
bug open for this

	http://tracker.newdream.net/issues/266

but it hasn't been prioritized.  Sorry for the confusion!  It will happen 
soon.  

In the meantime, you need

	 -o secretfile=/path/to/secretfile,name=access_fs

sage

[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