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 <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
