Domain data remains in DB after domain is deleted

Bug #1360391 reported by Sukwon Oh
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
In Progress
Medium
Ajaya Agrawal

Bug Description

Hi, I am wondering if the following is a security vulnerability.

Steps:

1. domain1 is created.
+---------+--------------------------------------------------------------------------------+
| Field | Value |
+---------+--------------------------------------------------------------------------------+
| enabled | True |
| id | 4d6d19ae738c4a56af6433206fa9755b |
| links | {u'self': u'http://0.0.0.0:35357/v3/domains/4d6d19ae738c4a56af6433206fa9755b'} |
| name | domain1 |
+---------+--------------------------------------------------------------------------------+

2. domain1 is disabled

3. group1 is created on another domain
+-------------+-------------------------------------------------------------------------------+
| Field | Value |
+-------------+-------------------------------------------------------------------------------+
| description | |
| domain_id | default |
| id | ac91ca33665241c48b20d7f121d52ba0 |
| links | {u'self': u'http://0.0.0.0:35357/v3/groups/ac91ca33665241c48b20d7f121d52ba0'} |
| name | group1 |
+-------------+-------------------------------------------------------------------------------+

4. role1 is granted to group1 for domain1
+----------------------------------+----------------------------------+----------------------------------+---------+----------------------------------+
| Role | User | Group | Project | Domain |
+----------------------------------+----------------------------------+----------------------------------+---------+----------------------------------+
| 9fe2ff9ee4384b1894a90878d3e92bab | 935d2f23300f4effbfd9c258cd71b329 | | | default |
| 1682a8d5ad6546c9ab627c010d9caf00 | | ac91ca33665241c48b20d7f121d52ba0 | | 4d6d19ae738c4a56af6433206fa9755b |
+----------------------------------+----------------------------------+----------------------------------+---------+----------------------------------+

5. domain1 is deleted

6. role1 is still granted to group1 for domain1
+----------------------------------+----------------------------------+----------------------------------+---------+----------------------------------+
| Role | User | Group | Project | Domain |
+----------------------------------+----------------------------------+----------------------------------+---------+----------------------------------+
| 9fe2ff9ee4384b1894a90878d3e92bab | 935d2f23300f4effbfd9c258cd71b329 | | | default |
| 1682a8d5ad6546c9ab627c010d9caf00 | | ac91ca33665241c48b20d7f121d52ba0 | | 4d6d19ae738c4a56af6433206fa9755b |
+----------------------------------+----------------------------------+----------------------------------+---------+----------------------------------+

Since, domain id is created using uuid, in case of a domain id collision when a new domain is created, (new domain's id is exactly '4d6d19ae738c4a56af6433206fa9755b'), won't this give anyone whose's a member of group1, role1 for the new domain?

Thank you

Revision history for this message
Dolph Mathews (dolph) wrote :

Yes, it will... but the odds of that happening are so astronomically low that we don't consider it to be a vulnerability so much as something we need to work better to clean up (orphaned data).

Changed in keystone:
importance: Undecided → Medium
status: New → Triaged
wanghong (w-wanghong)
Changed in keystone:
assignee: nobody → wanghong (w-wanghong)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/127433

Changed in keystone:
status: Triaged → In Progress
Revision history for this message
Henry Nash (henry-nash) wrote :

As an aside, although someone marked #1277847 as a duplicate of this big - in fact, it is the other way round since #1277847 was raised well before this bug....and in fact I think it describes the problem more clearly.

Changed in keystone:
assignee: wanghong (w-wanghong) → Adam Young (ayoung)
Changed in keystone:
assignee: Adam Young (ayoung) → Ajaya Agrawal (ajayaa)
Revision history for this message
Samuel de Medeiros Queiroz (samueldmq) wrote :

I agree with Henry Nash. The other bug report is older and more accurate. I am marking this one as duplicated and updating the existing patch accordingly.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.