<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 12:40 PM, Morgan Fainberg <span dir="ltr"><<a href="mailto:m@metacloud.com" target="_blank">m@metacloud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
As Dolph stated, V3 is where the policy file protects. This is one of the many reasons why I would encourage movement to using V3 Keystone over V2.</div><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">The V2 API is officially deprecated in the Icehouse cycle, I think that moving the decorator potentially could cause more issues than not as stated for compatibility. I would be very concerned about breaking compatibility with deployments and maintaining the security behavior with the encouragement to move from V2 to V3. I am also not convinced passing the context down to the manager level is the right approach. Making a move on where the protection occurs likely warrants a deeper discussion (perhaps in Atlanta?).</div>
</div></blockquote><div><br></div><div>++ I <i>should</i> have written "could be moved to the manager layer." I don't actually think they should, at least at the moment. With v2.0 gone, it would be a more interesting, more approachable discussion.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Cheers,</div><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
Morgan Fainberg</div><div><div class="h5"><div></div> <br><p style="color:#a0a0a8">On December 12, 2013 at 10:32:40, Dolph Mathews (<a href="mailto://dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>) wrote:</p>
<blockquote type="cite"><span><div><div>
<div dir="ltr">The policy file is protecting v3 API calls at the
controller layer, but you're calling the v2 API. The policy
decorators should be moved to the manager layer to protect both
APIs equally... but we'd have to be very careful not to break
deployments depending on the trivial "assert_admin" behavior (hence
the reason we only wrapped v3 with the new policy
decorators).</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Dec 12, 2013 at 1:41 AM, Qiu Yu
<span dir="ltr"><<a href="mailto:unicell@gmail.com" target="_blank">unicell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Hi,</div>
<div><br></div>
<div>I was trying to fine tune some keystone policy rules.
Basically I want to grant "create_project" action to user in "ops"
role. And following are my steps.</div>
<div><br></div>
<div>1. Adding a new user "usr1"</div>
<div>2. Creating new role "ops"</div>
<div>3. Granting this user a "ops" role in "service" tenant</div>
<div>4. Adding new lines to keystone policy file</div>
<div><br></div>
<div>
<div> "ops_required":
[["role:ops"]],</div>
<div> "admin_or_ops":
[["rule:admin_required"], ["rule:ops_required"]],</div>
</div>
<div><br></div>
<div>5. Change</div>
<div><br></div>
<div> "identity:create_project":
[["rule:admin_required"]],</div>
<div> to</div>
<div> "identity:create_project":
[["rule:admin_or_ops"]],<br></div>
<div><br></div>
<div>6. Restart keystone service</div>
<div><br></div>
<div>keystone tenant-create with credential of user "usr1" still
returns 403 Forbidden error.</div>
<div>“You are not authorized to perform the requested action,
admin_required. (HTTP 403)”<br></div>
<div><br></div>
<div>After some quick scan, it seems that create_project function
has a hard-coded assert_admin call[1], which does not respect
settings in the policy file.</div>
<div><br></div>
<div>Any ideas why? Is it a bug to fix? Thanks!</div>
<div>BTW, I'm running keystone havana release with V2 API.</div>
<div><br></div>
<div>[1] <a href="https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L105" target="_blank">https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L105</a><br>
</div>
<div><br></div>
<div>Thanks,</div>
<div>--<br>
Qiu Yu</div>
</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>
<br clear="all">
<div><br></div>
--<br>
<div><br></div>
-Dolph</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></div></div></span></blockquote></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>