[xena][cephfs] Manila availability zone allow to use unauthorized share-type

[Romain]

Description
===========
It's currently possible to access a share type without any authorization. It seems availability zone has precedence over share type access. Meaning if you have only one private share type in your availability zone, everyone can access it through the AZ.

Maybe some updates from https://bugs.launchpad.net/manila/+bug/1991938 fixed it but I currently cannot test it

Steps to reproduce
==================

A chronological list of steps which will help reproduce the issue you hit:
* Create a share type "st1" in AZ "az1"
* Create a private share type "st2" in AZ "az2"
* Do not allow your project to access st2
* Create a share with name "shareOK" of type st1 in az1
* Create a share with name "shareBUG" of type st1 in az2

Then you have to access your FSAL file:

ShareOK:
    FSAL {
        Name = "Ceph";
        Filesystem = "cephfs_az1";

ShareBUG:
    FSAL {
        Name = "Ceph";
        Filesystem = "cephfs_az2";

Despite having 2 types differents and being unable to access to "st2", data will finally end into the forbidden cephfs pool

Expected result
===============
User should not be able to create the share if the selected AZ does not have a public share type

Actual result
=============
User can create a share in a ceph fs pool without any authorization

Environment
===========
dpkg -l | grep manila
ii manila-common 1:13.0.3-0ubuntu1~cloud0 all OpenStack shared file system as a service - common files

On Ubuntu focal

Logs & Configs
==============

[cephfs_az2]
share_backend_name = cephfs_nfs_az2
ganesha_rados_store_enable = True
ganesha_rados_store_pool_name = nfs-ganesha
driver_handles_share_servers = False
share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_protocol_helper_type = NFS
cephfs_conf_path = /etc/ceph/ceph.conf
cephfs_auth_id = manila
cephfs_cluster_name = ceph
cephfs_ganesha_server_is_remote = False
cephfs_ganesha_server_ip = x.x.x.x
cephfs_filesystem_name = cephfs_az2
backend_availability_zone = az2
ganesha_export_template_dir = /etc/manila/tmpl-az2/

[cephfs_nfs_az1]
share_backend_name = cephfs_nfs_az1
ganesha_rados_store_enable = True
ganesha_rados_store_pool_name = nfs-ganesha
driver_handles_share_servers = False
share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_protocol_helper_type = NFS
cephfs_conf_path = /etc/ceph/ceph.conf
cephfs_auth_id = manila
cephfs_cluster_name = ceph
cephfs_ganesha_server_is_remote = False
cephfs_ganesha_server_ip = x.x.x.x
cephfs_filesystem_name = cephfs_az1
backend_availability_zone = nova
ganesha_export_template_dir = /etc/manila/tmpl-az1/

Best Regards,
Romain

[Goutham Pacha Ravi (gouthamr)]

Hi Romain,

Thanks for this bug report. Can we see the extra specs configured in share types st1 and st2? Are you using the "availability_zones" extra_spec to constrain your share types to specific AZs?

[Romain (romain-chanu)]

Hi,

I do not use availability_zones extra_spec. I use these specs on both share types:

driver_handles_share_servers : False
storage_protocol : NFS
vendor_name : Ceph

Problem is not about forcing a share type according to user's availability zone choice but a user can access to a ceph pool without any authorization.

openstack share type access list st2
project1_id
project2_id

If I create a share in project3 I should not be able to use st2. I do not see it but user can still access ceph's pool through AZ choice.

You will find below my 2 shares:

+--------------------------------------+---------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
| ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone |
+--------------------------------------+---------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
| id1 | ShareBUG | 99 | NFS | available | False | st1 | | az2 |
| id2 | ShareOK | 25 | NFS | available | False | st1 | | az1 |
+--------------------------------------+---------------+------+-------------+-----------+-----------+-----------------+------+-------------------+

But ShareBUG with share type "st1" will write data into ceph's pool matching "st2"

[Goutham Pacha Ravi (gouthamr)]

Thanks for your response;

If you want to restrict a share type to specific backend, and prevent other share types from matching that backend, you need those instructions coded as extra-specs - otherwise there's no way for manila to tell these share types and backends apart.

In the scenario you provided, you have two share types and you want to isolate each to a specific backend. You can do that in several ways; a couple of them are:

1) Set "share_backend_name" as an extra-spec in each of the share types to match or exclude the exact backend you want (cephfs_az2, cephfs_nfs_az1)

  `` manila type-key st1 set share_backend_name='cephfs_nfs_az1' ``
  `` manila type-key st2 set share_backend_name='s!= cephfs_nfs_az1' ``

2) Set "availability_zones" extra spec to restrict what AZs users of the share type can work within, for example,

  `` manila type-key st1 set availability_zones=nova `` and
  `` manila type-key st2 set availability_zones=az2 ``

More details here: https://docs.openstack.org/manila/latest/admin/capabilities_and_extra_specs.html

Prior to creating share types, you can use "manila pool-list --detail" to see what each backend reports to the scheduler so you can figure out what extra specs are possible.