Previously, when the CephFS native driver was configured for OpenStack File Share service (manila), denying access of a Ceph auth ID to a share was supposed to evict
the client based on the auth ID and the share accessed. However, the driver invoked the 'ceph_volume_client' library evict function method incorrectly and the clients using the ID continued to have access to the share.
With this update, the calling signature for the 'ceph_volume_client' library evict method in the OpenStack File Share service CephFS native driver has been corrected. As a result, when access to a share is denied for a Ceph auth ID, clients using that ID are no longer able to access that share.
When the CephFS native driver is configured for manila,
denying access of a ceph auth ID to a share is supposed to evict
the client based on the auth ID and the share accessed. Currently,
the driver tries to do this by incorrectly [1] using CephFSVolumeClient.evict() (part of of a Ceph library module), which
itself does not yet evict clients based on auth ID and
path accessed [2].
Fix: Wait for the relevant ceph_volume_client library change, and based
on the change evict clients correctly when denying access.
[1] https://github.com/openstack/manila/commit/cbb316babf1648f46c7e31e6415470df29dd5377#diff-4256e8eb2400d0325fe689bc36010201R230
[2] http://tracker.ceph.com/issues/15045
Comment 6Dustin Schoenbrun
2016-08-11 20:16:57 UTC
I was able to test this against the following packages:
-- OpenStack Server --
openstack-manila-2.0.0-4.el7ost.noarch
python-manilaclient-1.8.1-1.el7ost.noarch
python-manila-2.0.0-4.el7ost.noarch
openstack-manila-share-2.0.0-4.el7ost.noarch
-- Fedora 24 Ceph Client --
ceph-fuse-10.2.2-2.fc24.x86_64
-- Ceph Cluster --
ceph-selinux-10.2.2-32.el7cp.x86_64
ceph-ansible-1.0.5-31.el7scon.noarch
libcephfs1-10.2.2-32.el7cp.x86_64
ceph-common-10.2.2-32.el7cp.x86_64
ceph-base-10.2.2-32.el7cp.x86_64
ceph-mon-10.2.2-32.el7cp.x86_64
ceph-release-1-1.el7.noarch
python-cephfs-10.2.2-32.el7cp.x86_64
ceph-mds-10.2.2-32.el7cp.x86_64
ceph-osd-10.2.2-32.el7cp.x86_64
I was able to create a Manila share, allow access to a Cephx identity, and then delete the share without any issue. I was also able to create a Manila share, allow access to a Cephx identity, mount the share on the Fedora host, and then delete the share without it becoming stuck in "deleting" status. The mount point will remain on the Fedora host and queries to the mount point will hang, but the mount point can be forcibly removed with "umount -f <mount_point>" without issue.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHEA-2016-1761.html
When the CephFS native driver is configured for manila, denying access of a ceph auth ID to a share is supposed to evict the client based on the auth ID and the share accessed. Currently, the driver tries to do this by incorrectly [1] using CephFSVolumeClient.evict() (part of of a Ceph library module), which itself does not yet evict clients based on auth ID and path accessed [2]. Fix: Wait for the relevant ceph_volume_client library change, and based on the change evict clients correctly when denying access. [1] https://github.com/openstack/manila/commit/cbb316babf1648f46c7e31e6415470df29dd5377#diff-4256e8eb2400d0325fe689bc36010201R230 [2] http://tracker.ceph.com/issues/15045