Open Stack

Hi Christian,

There were changes proposed recently that documented this behavior [1] [2],
but they haven't been merged yet.

You're using v2.0, correct?

The v2.0 API enforces policy/context at the controller layer [3], which
calls assert_admin. By the looks of it, assert_admin is hardcoded to check
for the 'admin_required' rule [4]. This is probably why you're seeing it
work when you add the '_member_' role to the 'admin_required' rule, but not
when you add '_member_' to the policy of the call.

Version 3 does this a little bit differently, which uses a different
mechanism than 'assert_admin' for enforcing policy [5]. It doesn't look
like the filterprotected method uses the hard coded check that lives in
assert_admin [6]. The behavior you're looking for might be different
between v2.0 and v3. Given that it's hard coded to look for the
'admin_required' rule in v2.0, and not in v3.



[1] https://review.openstack.org/#/c/123862/3
[2] https://review.openstack.org/#/c/124638/
[3]
https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L36-L39
[4]
https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/wsgi.py#L301
[5]
https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L226
[6]
https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/controller.py#L169


On Tue, Jan 27, 2015 at 11:08 AM, Fischer, Matt <matthew.fischer at twcable.com
> wrote:

> On 1/26/15, 8:46 AM, "Christian Berendt" <berendt at b1-systems.de> wrote:
>
> >On 01/26/2015 04:02 PM, Fischer, Matt wrote:
> >> Is there any reason that the user can¹t just run keystone catalog which
> >> does not require admin permissions?
> >
> >Matt, this is just an example. We tried it with different list methods
> >and it is also not working.
> >
> >We read your blog post about the topic
> >(http://www.mattfischer.com/blog/?p=524) and it is working for us for
> >services like Neutron or Nova. But not for Keystone.
> >
> >Christian.
>
>
> Christian,
>
> I discussed this with the keystone folks this morning and it looks like
> there are some internal checks for admin that are causing this. One of the
> keystone team will be following-up with more details.
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150128/d3ab9298/attachment.html>