Comment 6 for bug 1779003

As Slawek pointed out in the code review, the proposed fix does cause another problem with the evaluation of the "update_rbac_policy:target_tenant" rule. The proposed fix changes Neutron to look at current attribute values instead of attribute values from the API request, but for the "update_rbac_policy:target_tenant" rule, the desire is to look at the new value of "target_tenant" attribute to determine if its wildcarded or not.

So which is it? Should Neutron be interpreting a field/attribute value as
1) current value in the database or
2) as new value found in the API request?

If the answer is #2, then the rules "rule:shared" and "rule:external" are not being used correctly in this rule:

     "get_network": "rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc",

When I read this rule, I expect that network information can be retrieved only if:
   a) the user with that role is the owner of the network
   b) the user with that role is admin role
   c) the user with that role is advsvc role
   d) the network is *currently* shared
   e) the network is *currently* external

But let's say a non-owner, non-admin, non-advsvc user is trying to change the non-shared, non-external network to be shared. The user will not have permission to update the shared attribute, so this "get_network" rule is going to be invoked. If neutron looks at the new value of shared from the API request, then "get_network" will succeed, and the wrong error code will be returned (403 instead of 404).