Greetings, I have noticed a discrepancy in the way policies are enforced between v2 and v3 API calls. Namely, v3 calls pass the user and target contexts to the policy.enforce method, while v2's assert_admin only takes the user context into consideration. The differences appear here as far as I can tell: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L613 (v3) and here: https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L256 (v2)
I've experimented with roughly patching the v2 API to take the target context into account, but I have run into problems when manually testing it against the CLI. For example, calling 'keystone user-role-add' will list users, projects and roles to retrieve IDs prior to adding the role to a user, but these calls are admin only, and no target context is passed when doing these calls so they will fail if you want, for example, "tenant admins" in v2 (as in admin rights limited to actions related to a specific tenant). Therefore, such a patch would probably involve some work on the CLI as well. I am aware the notion of "tenant admin" should probably be treated as business logic outside of keystone, but concerning the difference of treatment between policies enforcements: * Was it a design decision ? * If not, should the v2 API be patched so that the target context can be used with policies ? More generally speaking, what's the common opinion on this since the v2 API is deprecated from now on ? Matthieu Huin m...@enovance.com http://www.enovance.com 11 bis rue roquépine – 75008 PARIS France _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
