Open Stack

On Thu, Jul 24, 2014 at 9:48 AM, Scott Devoid <devoid at anl.gov> wrote:

> 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?
>

We haven't really been using or thinking about this as a feature, more a
potential backwards compatibility headache. I think it makes sense to just
go through the deprecation path so people aren't confused about whether
they should start using "owner_is_tenant=False" (they shouldn't).


> 2. From glance developers, what kind of permissions / policy scenarios do
> you actually expect to work?
>

There is work going on now to support using images as targets. Of course,
the policy api wants enforce calls to only ever work with targets that are
dictionaries, which is a great way to race to the bottom in terms of
programming practices. But oh well.

Spec for supporting use of images as targets is here:
https://blueprints.launchpad.net/glance/+spec/restrict-downloading-images-protected-properties
https://github.com/openstack/glance-specs/blob/master/specs/juno/restrict-downloading-images.rst


>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/20140729/21a7b60e/attachment.html>