On Tue, Oct 10, 2017 at 5:40 PM, Shawfeng Dong <shaw@xxxxxxxx> wrote:
> 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.
The "fs authorize" command is a new thing that's meant to make it
easier, so that people don't have to know the syntax of the path=
stuff, and so that they don't have to manually list out their data
pools etc.
> 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?
Clients never need access to the metadata pool. Was something giving
them access?
John
>
> 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==
>> >> 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.
>>
>> I confirm it works perfectly ! it should be added to the documentation. :)
>>
>> # 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
>
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
