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

Bug #1960247 reported by Takashi Kajinami
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Opinion
Wishlist
Takashi Kajinami

Bug Description

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

description: updated
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

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

Changed in nova:
status: New → In Progress
Changed in nova:
assignee: nobody → Takashi Kajinami (kajinamit)
Revision history for this message
Ghanshyam Mann (ghanshyammann) wrote (last edit ):

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.

Changed in nova:
importance: Undecided → Wishlist
Revision history for this message
sean mooney (sean-k-mooney) wrote :

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.

Changed in nova:
status: In Progress → Opinion
Revision history for this message
Takashi Kajinami (kajinamit) wrote :

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.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (master)

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers