server suspend action allows authorization by user_id while server resume action does not

[Takashi Kajinami]

Description
===========
Since the following change was merged, nova allows authorization by user_id for server suspend action.

https://review.opendev.org/c/openstack/nova/+/353344

However the same is not yet implemented in resume action and this results in inconsistent policy rule for corresponding two operations.

Steps to reproduce
==================
* Define policy rules like the following example
  "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"
  "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"
* Create a server by a non-admin user
* Suspend the server by the user
* Resume the server by the user

Expected result
===============
Both suspend and resume are accepted

Actual result
=============
Only suspend is accepted and resume fails with

ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-...)

Environment
===========
This issue was initially reported as one found in stable/xena deployment.
 http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027078.html

Logs & Configs
==============
N/A

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/nova/+/828168

[Ghanshyam Mann (ghanshyammann)]

Nova does not restrict the policy by user_id except keypairs API. We have kept it for a few of the destructive actions (for backwards compatibility) and intent to remove them too in future. I remember we discussed this in 2016 but I could not find the ML thread for that but
the consensus that time was we do not intend to support user_id based restriction permission in the API.

This is the spec where we kept the user_id support for destructive actions and the reason.

https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html

As we are moving our policy to new defaults (with new direction), after that we should discuss removing all the user_id enforcement support except keypair. But definitely should not extend it for any other action.

[sean mooney (sean-k-mooney)]

ack i kind of agree with gmann here
gmann is correct that this does not align with the direction we are moving in with our new policy/rbac work and that our intent was to eventually remove it outside of keypairs.

the spec linked above clearly state what our intentions were and the enpoint on which it could be used. as such I'm going to update this to invalid but we can continue this conversation on the mailing list, irc or in the nova team meeting.

[Takashi Kajinami (kajinamit)]

It's good discussion was concluded while I was sleeping.

So according to the discussion in ML(find details in the link I posted), I'll abandon the patch.
In short we are inclined to remove support of user_id in favor of SRBAC work which is not very consistent with it.

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Takashi Kajinami <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/nova/+/828168
Reason: See bug for details.