This bug was initially created as a copy of Bug #1916507 which applies to OSP 16.1+ that uses RHCS 4.2

I am copying this bug to ensure that we test the fix in RHCS 3.3, which affects OSP 13

Description of problem:

CVE-2020-27781 details a now un-embargo'ed issue with manila and native cephfs. The description from the CVE follows:

OpenStack Manila can provide users with Native CephFS shared file
systems [1]. When a user creates a "share" (short for "shared file
system") via Manila, a CephFS "subvolume" is created on the Ceph
cluster and exported to the manila user. After creating their share, a
user can specify who has access to the share with the help of "cephx"
client user names. A cephx client corresponds to Ceph Client Users
[2]. When access is provided, a client user key is returned via
manila. The interaction between manila and CephFS is driven by two
important parts:
 - The CephFS driver in manila [3]
 - The "ceph_volume_client" python interface driver in ceph [4]

The problem here is that OpenStack Manila users can request access to
a share to any arbitrary cephx user, including privileged pre-existing
users and the interface drivers will retrieve the access key of that
user along with providing access to the share. This access key is then
visible to all users of the OpenStack project that owns the share.
With the help of any prior capabilities of the pre-existing cephx
client user, an attacker has unintended access to the access key of
the user and can target any resource that the user has access to. An
attacker can even obtain the default ceph "admin" user's key in this
manner, and execute any commands as the ceph administrator.

[1] https://docs.openstack.org/manila/latest/admin/cephfs_driver.html
[2] https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/4/html/administration_guide/ceph-user-management
[3] https://opendev.org/openstack/manila/src/commit/7b15796aa5567868e30a6b2b80c57006cfa4f085/manila/share/drivers/cephfs/driver.py
[4] https://github.com/ceph/ceph/blob/c10a7240b657553c366fe62aca92e93d35b166e9/src/pybind/ceph_volume_client.py
[5] https://ceph.io/security/




Version-Release number of selected component (if applicable): OSP 16.x


How reproducible: Always


Steps to Reproduce:
1. When using the native cephfs backend on manila, allow access to "admin" user. 
2. Use a pre-existing cephfs client user, allow access to this user

Actual results:

Manila will fetch you the secret access key for the user you allow access to - and it performs no validation if you really ought to have someone's key. So you could have the "admin"'s secret key if you requested it, and basically have a privileged access to the ceph cluster.


Expected results:

CephFS should refuse to leak access secrets for pre-existing, possibly more privileged users via Manila. 


Additional info: