Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140703/3e11ac8b/attachment.html>