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