Dafna Ron of Red Hat reports: Description of problem: when I try to create an image with tenant name and not tenant ID, the image is not created and no errors are issued. you simply cannot find the image. Version-Release number of selected component (if applicable): openstack-glance-2013.1.3-1.el6ost.noarch How reproducible: 100% Steps to Reproduce: 1. install AIO with local tgt storage (using packstack) 2. create a tenant and a user 3. create an image for the tenant using the tenant name 4. run glance image-list while logging in with user 5. run the same create command using tenant ID 6. run glance image-list while logging in with the user Actual results: image is no created with tenant name. no errors or indicators that the image was not created. Expected results: image should be created with tenant name if we decided not to allow create of image with tenant name we should block the command from running with missing param error ======== Upon further investigation Flavio Percoco of Red Hat reports: Ayal suggested this could also be a security issue. I went ahead and tested current behavior and indeed, this behavior could be used to inject images to other users. Scenario: - Create an image using user1 - Pick tenant's id of user2 and add it as a member of the image user1 just created - Use user2 to list images. This will list the image user1 created. I think this is an issue because it allows user from other tenants to sneak images with a backdoor to other tenants.
This was discussed upstream. The analysis seems to be: * this is actually a feature which has been present since the Glance version 1.0 API * retroactively fixing this would break previous expected behavior which has beneficial uses * this has been resolved in the version 2.1 API via a two-step process: a user can create an image for another tenant, which then goes in to a 'pending state' and must be accepted by the other tenant in order to be used.
The risks associated with fixing this bug in OpenStack 3.0 are greater than its security impact as it would require default behavior to be changed. A future release of OpenStack may address this issue.
As Lon mentioned, this was discussed upstream and a OSSN[0] was recently released. I propose closing this bug as 'won't fix' based on the points raised by Lon, since this is not present in API v2 and will be fully supported by the client as part of Icehouse - RHOS 5.0. [0] https://bugs.launchpad.net/ossn/+bug/1226078/comments/11
(In reply to Flavio Percoco from comment #4) > I propose closing this bug as 'won't fix' based on the points raised by Lon, > since this is not present in API v2 and will be fully supported by the > client as part of Icehouse - RHOS 5.0. Kurt, any objections to fpercoco's plan here?