On Thu, Jan 23, 2020 at 2:36 PM Ilya Dryomov <[email protected]> wrote: > > On Wed, Jan 22, 2020 at 6:18 PM Hayashida, Mami <[email protected]> > wrote: > > > > Thanks, Ilya. > > > > I just tried modifying the osd cap for client.testuser by getting rid of > > "tag cephfs data=cephfs_test" part and confirmed this key does work (i.e. > > lets the CephFS client read/write). It now reads: > > > > [client.testuser] > > key = XXXYYYYZZZ > > caps mds = "allow rw" > > caps mon = "allow r" > > caps osd = "allow rw" // previously "allow rw tag cephfs data=cephfs_test" > > > > I tried removing either "tag cephfs" or "data=cephfs_test" (and leaving the > > other), but neither worked. > > > > Now, here is my question: will not having the "allow rw tag cephfs > > data=<file system name>" (under osd caps) result in a security/privacy > > loophole in a production cluster? (I am still trying to assess whether > > having a Cache Tier behind CephFS is worth all the headaches...) > > It's probably not worth it. Unless you have a specific tiered > workload in mind and your cache pool is large enough for it, I'd > recommend staying away from cache tiering. > > "allow rw" for osd is only marginally more restrictive than > client.admin's "allow *", allowing the user to read/write every object > in the cluster. Scratch my reply about doing it by hand -- try the > following: > > $ ceph osd pool application enable cephfs-data-cache cephfs > $ ceph osd pool application set cephfs-data-cache cephfs data cephfs_test > $ ceph fs authorize cephfs_test ... (as before) > > You will see the same "allow rw tag cephfs data=cephfs_test" cap in > "ceph auth list" output, but it should allow accessing cephfs-data-cache.
Dropping [email protected] and resending to [email protected]. Thanks, Ilya _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
