os-flavor-access API policy should be admin only

[Ghanshyam Mann]

os-flavor-access API policy is default to admin_or_owner[1] but API is allowed for everyone.

This is because API does not pass the server project_id in policy target
- https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/api/openstack/compute/flavor_access.py#L45

and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access)
- https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191

I do not think there is owner things for flavor as multiple tenant can be added to access the flavor. I think we should default this policy to admin only and admin only should be able to list all the tenants who has access to specific flavor.

[1]
- https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/policies/flavor_access.py#L49

[Ghanshyam Mann (ghanshyammann)]

If we want to make it owner basis then we need to add some magic of multi-owner verification on nova side. This can be done by checking the context.can() in the loop for every tenant has access to that flavor.

But again quesiton is tenantA will be able to know all tenant info have access to that flavor.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/713697
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=51abb44ee7125f52f4c7be47473402107b1f7e05
Submitter: Zuul
Branch: master

commit 51abb44ee7125f52f4c7be47473402107b1f7e05
Author: Ghanshyam Mann <email address hidden>
Date: Wed Mar 18 06:56:05 2020 -0500

    Add new default roles in os-flavor-access policies

    This adds new defaults roles in os-flavor-access API policies.
    This policy is default to SYSTEM_ADMIN role for add/remove
    tenant access and SYSTEM_READER for list the access information.

    Also add tests to simulates the future where we drop the deprecation
    fall back in the policy by overriding the rules with a version where
    there are no deprecated rule options. Operators can do the same by
    adding overrides in their policy files that match the default but
    stop the rule deprecation fallback from happening.

    Partial implement blueprint policy-defaults-refresh

    Closes-Bug: #1867840

    Change-Id: Ieeaafe923b78f03ddcbec18d8759aa1d76bcfcb1