admin user cannot delete other tenants' volumes by name

[Jay Bryant]

If a volume is created, with a display-name, via a non- administrator tenant and then the admin attempts to delete the volume using the display-name, the deletion fails.

The following steps were taking to recreate this bug:

1. Create a non-admin user. Create user, role, tenant firsly and then bound them.
[root@localhost ˜]# keystone tenant-create --name zhangg --description testid
+-------------+----------------------------------+
| Property | Value |
+-------------+----------------------------------+
| description | testid |
| enabled | True |
| id | 0ff45e7f7b944fbda34ed27238aa7ee0 |
| name | zhangg |
+-------------+----------------------------------+

[root@localhost ˜]# keystone user-create --tenant-id 0ff45e7f7b944fbda34ed27238aa7ee0 --name zhangg --pass xxxxxxxx
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| email | |
| enabled | True |
| id | e021b39742cc4307a8d2b81025c0ea96 |
| name | zhangg |
| tenantId | 0ff45e7f7b944fbda34ed27238aa7ee0 |
+----------+----------------------------------+
[root@localhost ˜]# keystone role-create --name zhangg
+----------+----------------------------------+
| Property | Value |
+----------+----------------------------------+
| id | 7bdfa3ef15a842ebbee56834b6d955a2 |
| name | zhangg |
+----------+----------------------------------+
[root@localhost ˜]# keystone user-role-add --user e021b39742cc4307a8d2b81025c0ea96 --role 7bdfa3ef15a842ebbee56834b6d955a2 --tenant 0ff45e7f7b944fbda34ed27238aa7ee0

(no output for this command)

2. Create a file as below and source that file. This will export new id and password.
export OS_USERNAME=zhangg
export OS_TENANT_NAME=zhangg
export OS_PASSWORD=xxxxxxxx
export OS_AUTH_URL=http://10.1.0.40:5000/v2.0/
export OS_REGION_NAME=RegionOne

3. Then create a volume.

4. Then source the admin user password. In my environment it is as below.
export OS_USERNAME=admin
export OS_TENANT_NAME=service
export OS_PASSWORD=xxxxxxxx
export OS_AUTH_URL=http://10.1.0.40:5000/v2.0/
export OS_REGION_NAME=RegionOne

5. Use cinder list --all-tenant 1. You can see all of the volumes for all tenant.

6. Try to delete the volume.

7. In this case, I create a volume zhanggvolume and try to delete it by admin.
[root@localhost cinder]# cinder list --all-tenant 1
+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
| e59dcd7b-af81-415d-932c-311be8e8eced | available | zhanggvolume2 | 1 | None | false | |
+--------------------------------------+-----------+---------------+------+-------------+----------+-------------+
[root@localhost cinder]# cinder delete zhanggvolume2
/usr/lib/python2.6/site-packages/cinderclient/shell.py:524: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  message = e.message
ERROR: No volume with a name or ID of 'zhanggvolume2' exists.

[Jay Bryant (jsbryant)]

Ok, I have tracked down the place where this is happening. When we are in do_delete we call _find_volume which eventually works its way down to findall. It appears to me that findall should be passing 'all_tenants=1' as an option to the the list function for volumes. This way the list of volumes returned is consistent with the access permissions of the user attempting to do the delete.

In the case that you have admin authority you get back your volumes as well as the other volumes on the system and then this bug is not encountered. There is no security hole opened as the non-admin user still only gets a list of volumes that he has access to returned.

I am working on coding up a solution for this.

[Rushi Agrawal (rushiagr)]

Jay, can you assign it to yourself if you're working on it? Else I'll take it up..

[Jay Bryant (jsbryant)]

Rushi, you had me worried for a minute as I remembered committing a change for this. For some reason the bug didn't get updated. Anyway, the fix for this was pushed up under this review: https://review.openstack.org/#/c/53909/ I will update the bug by hand.

[Thierry Carrez (ttx)]

Not released in a milestone yet