Open Stack

So it turns out that fixing this issue is not very simple. It turns out
that there are stubbed out openstack.common.policy checks in the glance-api
code, which are pretty much useless because they do not use the image as a
target. [1] Then there's a chain of API / client calls where it's unclear
who is responsible for validating ownership: python-glanceclient ->
glance-api -> glance-registry-client -> glance-registry-api ->
glance.db.sqlalchemy.api. Add to that the fact that request IDs are not
consistently captured along the logging path [2] and it's a holy mess.

I am wondering...
1. Has anyone actually set "owner_is_tenant" to false? Has this ever been
tested?
2. From glance developers, what kind of permissions / policy scenarios do
you actually expect to work?

Right now we have one user who consistently gets an empty 404 back from
"nova image-list" because glance-api barfs on a single image and gives up
on the entire API request...and there are no non-INFO/DEBUG messages in
glance logs for this. >:-/

~ Scott

[1] https://bugs.launchpad.net/glance/+bug/1346648
[2] https://bugs.launchpad.net/glance/+bug/1336958

On Fri, Jul 11, 2014 at 12:26 PM, Scott Devoid <devoid at anl.gov> wrote:

> Hi Alexander,
>
> I read through the artifact spec. Based on my reading it does not fix this
> issue at all. [1] Furthermore, I do not understand why the glance
> developers are focused on adding features like artifacts or signed images
> when there are significant usability problems with glance as it currently
> stands. This is echoing Sean Dague's comment that bugs are filed against
> glance but never addressed.
>
> [1] See the **Sharing Artifact** section, which indicates that sharing may
> only be done between projects and that the tenant owns the image.
>
>
> On Thu, Jul 3, 2014 at 4:55 AM, Alexander Tivelkov <ativelkov at mirantis.com
> > wrote:
>
>> Thanks Scott, that is a nice topic
>>
>> In theory, I would prefer to have both owner_tenant and owner_user to be
>> persisted with an image, and to have a policy rule which allows to specify
>> if the users of a tenant have access to images owned by or shared with
>> other users of their tenant. But this will require too much changes to the
>> current object model, and I am not sure if we need to introduce such
>> changes now.
>>
>> However, this is the approach I would like to use in Artifacts. At least
>> the current version of the spec assumes that both these fields to be
>> maintained ([0])
>>
>> [0]
>> https://review.openstack.org/#/c/100968/4/specs/juno/artifact-repository.rst
>>
>> --
>> Regards,
>> Alexander Tivelkov
>>
>>
>> On Thu, Jul 3, 2014 at 3:44 AM, Scott Devoid <devoid at anl.gov> wrote:
>>
>>>  Hi folks,
>>>
>>> Background:
>>>
>>> Among all services, I think glance is unique in only having a single
>>> 'owner' field for each image. Most other services include a 'user_id' and a
>>> 'tenant_id' for things that are scoped this way. Glance provides a way to
>>> change this behavior by setting "owner_is_tenant" to false, which implies
>>> that owner is user_id. This works great: new images are owned by the user
>>> that created them.
>>>
>>> Why do we want this?
>>>
>>> We would like to make sure that the only person who can delete an image
>>> (besides admins) is the person who uploaded said image. This achieves that
>>> goal nicely. Images are private to the user, who may share them with other
>>> users using the image-member API.
>>>
>>> However, one problem is that we'd like to allow users to share with
>>> entire projects / tenants. Additionally, we have a number of images (~400)
>>> migrated over from a different OpenStack deployment, that are owned by the
>>> tenant and we would like to make sure that users in that tenant can see
>>> those images.
>>>
>>> Solution?
>>>
>>> I've implemented a small patch to the "is_image_visible" API call [1]
>>> which checks the image.owner and image.members against context.owner and
>>> context.tenant. This appears to work well, at least in my testing.
>>>
>>> I am wondering if this is something folks would like to see integrated?
>>> Also for glance developers, if there is a cleaner way to go about solving
>>> this problem? [2]
>>>
>>> ~ Scott
>>>
>>> [1]
>>> https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L209
>>> [2] https://review.openstack.org/104377
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140724/ba266390/attachment.html>