Share stuck on "creating" status when using a private share type from other project

Bug #1885956 reported by Tom Barron on 2020-07-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Shared File Systems Service (Manila)
Medium
Tom Barron

Bug Description

Description of problem:
When creating a share using a private share from other tenant, i.e.
the tenant has no access to the share type, as expected it failed with 404,
but the share stuck on "creating" status.

Steps to Reproduce:
1. Create private share type on tenant "A".
2. Create a share on tenant "B" using the share type from tenant "A" by non-admin user

Actual results:
Share stuck on "creating" status

Expected results:
The share should not reach the creation process.
The share should not be listed in manila list.

Additional info:

On tenant "A":

(overcloud) [stack@undercloud-0 ~]$ manila type-list
+--------------------------------------+---------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
| ID | Name | visibility | is_default | required_extra_specs | optional_extra_specs | Description |
+--------------------------------------+---------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
| 696b41dc-22f2-4ae6-9996-66dba5ff2a26 | private | private | - | driver_handles_share_servers : False | | None |
+--------------------------------------+---------+------------+------------+--------------------------------------+--------------------------------------------+-------------+

(overcloud) [stack@undercloud-0 ~]$ manila type-access-list 696b41dc-22f2-4ae6-9996-66dba5ff2a26
+------------+
| Project_ID |
+------------+
+------------+

On tenant "B":

(overcloud) [stack@undercloud-0 ~]$ manila create --name share_member_user cephfs 1 --share-type private
ERROR: ShareTypeNotFound: Share type 696b41dc-22f2-4ae6-9996-66dba5ff2a26 could not be found. (HTTP 404) (Request-ID: req-2a9cf901-98fe-42af-9319-b57276e528a2)
(.venv) (overcloud) [stack@undercloud-0 ~]$ manila list
+--------------------------------------+-------------------+------+-------------+----------+-----------+-----------------+------+-------------------+
| ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone |
+--------------------------------------+-------------------+------+-------------+----------+-----------+-----------------+------+-------------------+
| 988854b1-5797-4b6b-9ca9-1ff5bedcf872 | share_member_user | 1 | CEPHFS | creating | False | private | | None |
+--------------------------------------+-------------------+------+-------------+----------+-----------+-----------------+------+-------------------+

Tom Barron (tpb) wrote :
Download full text (5.3 KiB)

Detailed Steps from Liron Kuchlani:

On admin project by admin user:
===============================

# Create project_a:

(overcloud) [stack@undercloud-0 ~]$ openstack project create project_a
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | |
| domain_id | default |
| enabled | True |
| id | 8c988874e83543cf8b155cf9cfd1356f |
| is_domain | False |
| name | project_a |
| options | {} |
| parent_id | default |
| tags | [] |
+-------------+----------------------------------+

# Create user user_a on project_a

(overcloud) [stack@undercloud-0 ~]$ openstack user create --project project_a --password redhat user_a
+---------------------+----------------------------------+
| Field | Value |
+---------------------+----------------------------------+
| default_project_id | 8c988874e83543cf8b155cf9cfd1356f |
| domain_id | default |
| enabled | True |
| id | 7dde343f6ff24f59ba67ce38da3ef9a7 |
| name | user_a |
| options | {} |
| password_expires_at | None |
+---------------------+----------------------------------+

# Assign member role to user_a user

(overcloud) [stack@undercloud-0 ~]$ openstack role add --user user_a --project project_a member

# Create private share type on admin project

(overcloud) [stack@undercloud-0 ~]$ manila type-create --is-public False admin-private-share-type False
+----------------------+--------------------------------------+
| Property | Value |
+----------------------+--------------------------------------+
| ID | c4ef9a32-b143-4c56-ba71-0a45f4d5848f |
| Name | admin-private-share-type |
| Visibility | private |
| is_default | - |
| required_extra_specs | driver_handles_share_servers : False |
| optional_extra_specs | |
| Description | None |
+----------------------+--------------------------------------+

(overcloud) [stack@undercloud-0 ~]$ manila type-access-list c4ef9a32-b143-4c56-ba71-0a45f4d5848f
+------------+
| Project_ID |
+------------+
+------------+

On project_a by user_a user:
============================

# Although the share type does not exist, try to create share with it

(overcloud) [stack@undercloud-0 ~]$ manila type-show c4ef9a32-b143-4c56-ba71-0a45f4d5848f
ERROR: No sharetype with a name or ID of 'c4ef9a32-b143-4c56-ba71-0a45f4d5848f' exists.

(overcloud) [stack@undercloud-0 ~]$ manila create --name share_member_user cephfs 1 --share-type ...

Read more...

Changed in manila:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Tom Barron (tpb)
milestone: none → victoria-2

Fix proposed to branch: master
Review: https://review.opendev.org/738941

Changed in manila:
status: Confirmed → In Progress
Liron Kuchlani (lkuchlan) wrote :

I found out that this issue only happens when the share type name is used
for creating the share.
Creating a share using share type id works as expected.

Reviewed: https://review.opendev.org/738941
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=f877deed5186cff3a7ecfbce2536e72fc6013895
Submitter: Zuul
Branch: master

commit f877deed5186cff3a7ecfbce2536e72fc6013895
Author: Tom Barron <email address hidden>
Date: Wed Jul 1 17:09:40 2020 -0400

    Enforce policy checks getting share-type by name

    Policy checks are skipped when looking up a share-type
    by name. This causes share creation attempts that specify
    a valid share-type to pass the early API check on share type
    even if the share type named is private and not shared with
    the user's project. The share creation fails later, but after
    the database record for the share is created. Although the
    operation fails with an ERROR, the share is stuck in CREATING
    state.

    Fix this issue by checking the user's project in the database
    API just as we do for share type lookups by uuid.

    Closes-bug: #1885956
    Change-Id: If5fe32c155fe0861b3ed86b862335e062796056b

Changed in manila:
status: In Progress → Fix Released

Reviewed: https://review.opendev.org/741278
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=e02cc6d6bc92e354bc7f4220a05ec6fedf2ecc9c
Submitter: Zuul
Branch: stable/ussuri

commit e02cc6d6bc92e354bc7f4220a05ec6fedf2ecc9c
Author: Tom Barron <email address hidden>
Date: Wed Jul 1 17:09:40 2020 -0400

    Enforce policy checks getting share-type by name

    Policy checks are skipped when looking up a share-type
    by name. This causes share creation attempts that specify
    a valid share-type to pass the early API check on share type
    even if the share type named is private and not shared with
    the user's project. The share creation fails later, but after
    the database record for the share is created. Although the
    operation fails with an ERROR, the share is stuck in CREATING
    state.

    Fix this issue by checking the user's project in the database
    API just as we do for share type lookups by uuid.

    Closes-bug: #1885956
    Change-Id: If5fe32c155fe0861b3ed86b862335e062796056b
    (cherry picked from commit f877deed5186cff3a7ecfbce2536e72fc6013895)

tags: added: in-stable-ussuri

Reviewed: https://review.opendev.org/741487
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=2f2ed258f7c273543495b5476af2c3558d51384d
Submitter: Zuul
Branch: stable/train

commit 2f2ed258f7c273543495b5476af2c3558d51384d
Author: Tom Barron <email address hidden>
Date: Wed Jul 1 17:09:40 2020 -0400

    Enforce policy checks getting share-type by name

    Policy checks are skipped when looking up a share-type
    by name. This causes share creation attempts that specify
    a valid share-type to pass the early API check on share type
    even if the share type named is private and not shared with
    the user's project. The share creation fails later, but after
    the database record for the share is created. Although the
    operation fails with an ERROR, the share is stuck in CREATING
    state.

    Fix this issue by checking the user's project in the database
    API just as we do for share type lookups by uuid.

    Closes-bug: #1885956
    Change-Id: If5fe32c155fe0861b3ed86b862335e062796056b
    (cherry picked from commit f877deed5186cff3a7ecfbce2536e72fc6013895)
    (cherry picked from commit e02cc6d6bc92e354bc7f4220a05ec6fedf2ecc9c)

tags: added: in-stable-train

Reviewed: https://review.opendev.org/742043
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=644cdf4e4ff965cb96b8cce5396042b6ac8abe7e
Submitter: Zuul
Branch: stable/stein

commit 644cdf4e4ff965cb96b8cce5396042b6ac8abe7e
Author: Tom Barron <email address hidden>
Date: Wed Jul 1 17:09:40 2020 -0400

    Enforce policy checks getting share-type by name

    Policy checks are skipped when looking up a share-type
    by name. This causes share creation attempts that specify
    a valid share-type to pass the early API check on share type
    even if the share type named is private and not shared with
    the user's project. The share creation fails later, but after
    the database record for the share is created. Although the
    operation fails with an ERROR, the share is stuck in CREATING
    state.

    Fix this issue by checking the user's project in the database
    API just as we do for share type lookups by uuid.

    Closes-bug: #1885956
    Change-Id: If5fe32c155fe0861b3ed86b862335e062796056b
    (cherry picked from commit f877deed5186cff3a7ecfbce2536e72fc6013895)
    (cherry picked from commit e02cc6d6bc92e354bc7f4220a05ec6fedf2ecc9c)
    (cherry picked from commit 2f2ed258f7c273543495b5476af2c3558d51384d)

tags: added: in-stable-stein

Reviewed: https://review.opendev.org/742123
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=11971a94d3205b42ee9e2f7c9978b4bb979fdd71
Submitter: Zuul
Branch: stable/rocky

commit 11971a94d3205b42ee9e2f7c9978b4bb979fdd71
Author: Tom Barron <email address hidden>
Date: Wed Jul 1 17:09:40 2020 -0400

    Enforce policy checks getting share-type by name

    Policy checks are skipped when looking up a share-type
    by name. This causes share creation attempts that specify
    a valid share-type to pass the early API check on share type
    even if the share type named is private and not shared with
    the user's project. The share creation fails later, but after
    the database record for the share is created. Although the
    operation fails with an ERROR, the share is stuck in CREATING
    state.

    Fix this issue by checking the user's project in the database
    API just as we do for share type lookups by uuid.

    Closes-bug: #1885956
    Change-Id: If5fe32c155fe0861b3ed86b862335e062796056b
    (cherry picked from commit f877deed5186cff3a7ecfbce2536e72fc6013895)
    (cherry picked from commit e02cc6d6bc92e354bc7f4220a05ec6fedf2ecc9c)
    (cherry picked from commit 2f2ed258f7c273543495b5476af2c3558d51384d)
    (cherry picked from commit 644cdf4e4ff965cb96b8cce5396042b6ac8abe7e)

tags: added: in-stable-rocky

Reviewed: https://review.opendev.org/743026
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=9b1b3957b992baf68624d1b8786949f4a4bc191a
Submitter: Zuul
Branch: stable/queens

commit 9b1b3957b992baf68624d1b8786949f4a4bc191a
Author: Tom Barron <email address hidden>
Date: Wed Jul 1 17:09:40 2020 -0400

    Enforce policy checks getting share-type by name

    Policy checks are skipped when looking up a share-type
    by name. This causes share creation attempts that specify
    a valid share-type to pass the early API check on share type
    even if the share type named is private and not shared with
    the user's project. The share creation fails later, but after
    the database record for the share is created. Although the
    operation fails with an ERROR, the share is stuck in CREATING
    state.

    Fix this issue by checking the user's project in the database
    API just as we do for share type lookups by uuid.

    Closes-bug: #1885956
    Change-Id: If5fe32c155fe0861b3ed86b862335e062796056b
    (cherry picked from commit f877deed5186cff3a7ecfbce2536e72fc6013895)
    (cherry picked from commit e02cc6d6bc92e354bc7f4220a05ec6fedf2ecc9c)
    (cherry picked from commit 2f2ed258f7c273543495b5476af2c3558d51384d)
    (cherry picked from commit 644cdf4e4ff965cb96b8cce5396042b6ac8abe7e)
    (cherry picked from commit 11971a94d3205b42ee9e2f7c9978b4bb979fdd71)

tags: added: in-stable-queens

Reviewed: https://review.opendev.org/740583
Committed: https://git.openstack.org/cgit/openstack/manila-tempest-plugin/commit/?id=a98919f25f265616b10352b481cdeb19b9361511
Submitter: Zuul
Branch: master

commit a98919f25f265616b10352b481cdeb19b9361511
Author: lkuchlan <email address hidden>
Date: Sun Jul 12 09:31:52 2020 +0300

    [Negative] Create share with non allowed share type

    This test was created due to a bug [1] that was found when
    creating a share type with non allowed share type.
    When creating a share using a private share from other tenant, i.e.
    the tenant has no access to the share type. As expected it failed
    with 404, but the share stuck on "creating" status.

    Note: This issue happens only when the share type name is used
    for creating the share.
    Creating a share using share type id works as expected.

    [1] https://bugs.launchpad.net/manila/+bug/1885956

    Depends-On: https://review.opendev.org/#/c/738941/
    Change-Id: I567abccdaa622193b44a9b70bc0481842d8d55f1
    Related-Bug: #1885956

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers