Policy violation didn't return 403

We should agree constant error code to fix this.
This is my proposal.

create -> 403
list
show -> 404 ( To hide another tenants entry)
delete
update

Hi Nachi, thanks for filing this. What is your proposal for delete and update? they seem to be inconsistent above as well.

My impression was that anything where an ID was provided (update, show, delete) returns a 404 to not indicate that the UUID in question was valid. Does that match your understanding? having list return 200 with an empty list seems to be inline with that.

Hi Dan

Sorry, my proposal was unclear.
IMO list should return 403, because if we are client developer, "200 but error" is not clean way to implement.

create -> 403
list -> 403
show -> 404
delete > 404
update > 404

The get operation for the API invokes check instead of enforce. If the check fails because the object has not access to the network, then the record is not added to the response list.

Implementing your strategy will imply that if all checks fail we should return a 403 error. Nevertheless, in this situation, it is likely that the tenant will not own any network - hence the list operation will simply return no results, and a 200 code will still be returned.

Another way of looking at this problem would be to say that the user should not have access to the resource as well, that is to say every time the /networks URI is accessed a 403 is returned.

I think this can be achieved by registering a check that looks at the resource you're accessing and fails the check if you don't have the credentials for accessing that resource. If you might like such approach I can prototype it for you.

I could see there are different kind of policy

(A) List operation policy
(B) Per Item policy

If Quantum support only B, return 200 is OK.
If Quantum support also A, it should return 403 because it is authorized error but request has no uuid.

Your reasoning is correct.

The current framework applies policies to CRUD operation of resources. "List" is seen as a sequence of gets.

I am not against coupling it with policies that define the right to perform operations such as list. Those policies might come hand when it comes to resource actions.

Nevertheless, I don't feel like the current policy system is broken. Hence, I won't feel like it's the end of the world if this is not sorted folsom-rc1.

Yes. I feel same.
So Quantum support only B, return 200 is OK. ( let's document this)
Also We should update doc because list never returns 403

So now problem is clear
We should fix just two API for rc1.

|delete subnet|403||
|delete port|403||

If we are currently returning 403 them we shoud return 404 on purpose for avoiding revealing valid but unaccessible uuids (see comment #2 from Dan).

in this case, yes, we definitely want to fix it for rc1

I couldn't reproduce 403 for delete_port with latest code, so I set this bug invalid

removing from RC1 based on invalid status.