Hi, On 13.09.2017 18:54, Adrian Turjak wrote: > Hello Keystone devs! > > I've been playing with some policy changes and realised that the trust > policy rules were mostly blank. Which, based on how the policy logic > works means that any authed user can list trusts: > https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L137-L142 > > But... in practive that doesn't appear to be the case, only admin can > list/create/etc trusts. Which is good since it doesn't really make sense > for any authed user to see all trusts (or does it?). What it does raise > is, does the policy actually work for trusts, or is an admin requirement > policy hardcoded somewhere for them? > > Now I've played with the keystone policy, setting an admin only policy > blank, lets say project list, does let any authed user to use that API. > So from that we know that a blank policy has that logic. The 'default' > rule only comes into play when a rule isn't present. Such as me setting > a policy as "rule:rule_that_doesnt_exist" which would invoke the default > rule, so we know that is happening here either. > > So... back to how I got here. The policy for trusts doesn't appear to > work as written. They are blank (and they probably shouldn't be), and > based on that policy, they should be visible to all authed users. Even > if I do put an explicit rule in them, they don't seem to take effect. > Can someone else confirm I'm not going mad? Or that potentially I'm > missing the point entirely (which for my sanity is also welcome :P).
Trusts are not controlled by policy.json. Checks for them are performed in code. So you're not mad ;) > I even checked if it was maybe extension specific, but the consumer > policy for the oauth extension does appear to work. If I blank it, any > authed user can list consumers. > > If I'm not mad, we should probably work out why this doesn't work, but > before we fix it, we should also add a better default rule since we > probably don't want all authed users seeing ALL trusts. I agree. Could you please create a bugreport? > Cheers, > Adrian > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev