Hi Yoann,
I confirm too that your recipe works!
We run CentOS 7:
[root@pulpo-admin ~]# uname -r
3.10.0-693.2.2.el7.x86_64
Here were the old caps for user 'hydra':
# ceph auth get client.hydra
exported keyring for client.hydra
[client.hydra]
key = AQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
caps mds = "allow rw"
caps mgr = "allow r"
caps mon = "allow r"
caps osd = "allow rw"
Our CephFS name is 'pulpos', when I tried to restrict CephFS client capabilities:
# ceph fs authorize pulpos client.hydra /hydra rw
I got this error:
Error EINVAL: key for client.hydra exists but cap mds does not match
In retrospect, the error means exactly what it says: the user caps and CephFS client caps must match! You can't *restrict* (narrow down) user caps with 'ceph fs authorize'.
For example, this won't work (I can't give 'rw' cap to all pools the restrict it):
# ceph auth caps client.hydra mon 'allow r' mgr 'allow r' osd 'allow rw' mds 'allow rw path=/hydra'
updated caps for client.hydra
# ceph fs authorize pulpos client.hydra /hydra rw
Error EINVAL: key for client.hydra exists but cap osd does not match
I find only this works:
# ceph auth caps client.hydra mon 'allow r' mgr 'allow r' osd 'allow rw pool=cephfs_data' mds 'allow rw path=/hydra'
updated caps for client.hydra
# ceph fs authorize pulpos client.hydra /hydra rw
[client.hydra]
key = AQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
```
But I still have 2 lingering questions:
1. If the user caps and CephFS client caps must match, why do we need 2 commands ('ceph auth' & 'ceph fs authorzie')? The first one is sufficient.
2. We only give 'rw' cap to the data pool and it works. Why is it unnecessary to give 'rw' cap to the metadata pool?
Best regards,
Shaw
On Tue, Oct 10, 2017 at 4:20 AM, Yoann Moulin <yoann.moulin@xxxxxxx> wrote:
>> I am trying to follow the instructions at:
>> http://docs.ceph.com/docs/master/cephfs/client-auth/
>> to restrict a client to a subdirectory of Ceph filesystem, but always get
>> an error.
>>
>> We are running the latest stable release of Ceph (v12.2.1) on CentOS 7
>> servers. The user 'hydra' has the following capabilities:
>> # ceph auth get client.hydra
>> exported keyring for client.hydra
>> [client.hydra]
>> key = AQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx== I confirm it works perfectly ! it should be added to the documentation. :)
>> caps mds = "allow rw"
>> caps mgr = "allow r"
>> caps mon = "allow r"
>> caps osd = "allow rw"
>>
>> When I tried to restrict the client to only mount and work within the
>> directory /hydra of the Ceph filesystem 'pulpos', I got an error:
>> # ceph fs authorize pulpos client.hydra /hydra rw
>> Error EINVAL: key for client.dong exists but cap mds does not match
>>
>> I've tried a few combinations of user caps and CephFS client caps; but
>> always got the same error!
>
> The "fs authorize" command isn't smart enough to edit existing
> capabilities safely, so it is cautious and refuses to overwrite what
> is already there. If you remove your client.hydra user and try again,
> it should create it for you with the correct capabilities.
# ceph fs authorize cephfs client.foo1 /foo1 rw
[client.foo1]
key = XXX1
# ceph fs authorize cephfs client.foo2 / r /foo2 rw
[client.foo2]
key = XXX2
# ceph auth get client.foo1
exported keyring for client.foo1
[client.foo1]
key = XXX1
caps mds = "allow rw path=/foo1"
caps mon = "allow r"
caps osd = "allow rw pool=cephfs_data"
# ceph auth get client.foo2
exported keyring for client.foo2
[client.foo2]
key = XXX2
caps mds = "allow r, allow rw path=/foo2"
caps mon = "allow r"
caps osd = "allow rw pool=cephfs_data"
Best regards,
--
Yoann Moulin
EPFL IC-IT
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph. com
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
