<div dir="ltr">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.<div>
<br></div><div>I am wondering...</div><div>1. Has anyone actually set "owner_is_tenant" to false? Has this ever been tested?</div><div>2. From glance developers, what kind of permissions / policy scenarios do you actually expect to work?</div>
<div><br></div><div>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. >:-/</div>
<div><br><div><div><div>~ Scott</div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/glance/+bug/1346648">https://bugs.launchpad.net/glance/+bug/1346648</a></div></div></div></div><div class="gmail_extra">[2] <a href="https://bugs.launchpad.net/glance/+bug/1336958">https://bugs.launchpad.net/glance/+bug/1336958</a><br>
<br><div class="gmail_quote">On Fri, Jul 11, 2014 at 12:26 PM, Scott Devoid <span dir="ltr"><<a href="mailto:devoid@anl.gov" target="_blank">devoid@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Hi Alexander,<div><br></div><div>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.</div>
<div><br></div><div>[1] See the **Sharing Artifact** section, which indicates that sharing may only be done between projects and that the tenant owns the image.</div></div><div class=""><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Thu, Jul 3, 2014 at 4:55 AM, Alexander Tivelkov <span dir="ltr"><<a href="mailto:ativelkov@mirantis.com" target="_blank">ativelkov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div style="font-size:small">Thanks Scott, that is a nice topic</div><div style="font-size:small"><br></div><div style="font-size:small">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. </div>
<div style="font-size:small"><br></div><div style="font-size:small">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])</div>
<div style="font-size:small"><br></div><div style="font-size:small">[0] <a href="https://review.openstack.org/#/c/100968/4/specs/juno/artifact-repository.rst" target="_blank">https://review.openstack.org/#/c/100968/4/specs/juno/artifact-repository.rst</a></div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><font>--<br></font><div dir="ltr"><font>Regards,<br>Alexander Tivelkov</font></div></div></div>
<br><br><div class="gmail_quote"><div><div>On Thu, Jul 3, 2014 at 3:44 AM, Scott Devoid <span dir="ltr"><<a href="mailto:devoid@anl.gov" target="_blank">devoid@anl.gov</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>
<div dir="ltr">Hi folks,<div><br></div><div>Background:</div><div><br></div><div>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.</div>
<div><br></div><div>Why do we want this?</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Solution?</div><div><br></div><div>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.</div>
<div><br></div><div>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]</div><div><br></div><div>~ Scott</div>
<div><br></div><div>[1] <a href="https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L209" target="_blank">https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L209</a><br></div>
<div>[2] <a href="https://review.openstack.org/104377" target="_blank">https://review.openstack.org/104377</a></div>
</div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>