<div dir="ltr">Ok, now I remember the discussion.<div>So:</div><div><br></div><div>- I am aware that support for user_id is implemented only for destructive operations</div><div>- I am aware that such support will be removed</div><div><br></div><div>Indeed in my policy files I am listing only destructive operations, apart from this resume operation (I can't remember why it is there).</div><div><br></div><div>And I was wrong when I said that the support for user_id for resume worked in Train.</div><div>I have just double checked and it seems to me that there is just a different behavior:</div><div><br></div><div>- In Train if you have: </div><div><br></div><div>"os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s",<br></div><div><br></div><div>you are able to resume your instance but you are able also to resume instances owned by other users of the same project</div><div><br></div><div>- In Xena if you have:</div><div><br></div><div>"os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"<br></div><div><br></div><div>you are not even able to resume your instances</div><div><br></div><div><br></div><div>So:</div><div>1: I am going to remove the user_id based policy for the resume operation in the policy file</div><div>2: I personally don't really need to have issue #1960247 addressed</div><div>3: Sorry for the noise !</div><div><br></div><div>Cheers, Massimo </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 7, 2022 at 6:32 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2022-02-07 at 11:10 -0600, Ghanshyam Mann wrote:<br>
>  ---- On Mon, 07 Feb 2022 11:06:06 -0600 Massimo Sgaravatto <<a href="mailto:massimo.sgaravatto@gmail.com" target="_blank">massimo.sgaravatto@gmail.com</a>> wrote ----<br>
>  > Thanks<br>
>  > Actually in the past support for user_id in the resume operation worked as expectedE.g. I have a train installation where I defined this rule in the policy.json file:<br>
>  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s",<br>
>  > <br>
>  > and it works<br>
>  > Cheers, Massimo<br>
>  > <br>
>  > <br>
>  > On Mon, Feb 7, 2022 at 5:03 PM Takashi Kajinami <<a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.com</a>> wrote:<br>
>  > Quickly checking the current code, it seems support for user_id was introduced to only suspend api[1] [1] <a href="https://review.opendev.org/c/openstack/nova/+/353344" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/353344</a><br>
>  > I've opened a bug for nova[2] because supporting consistent rules for suspend and resumemakes clear sense to me.<br>
>  >  [2] <a href="https://bugs.launchpad.net/nova/+bug/1960247" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1960247</a><br>
>  > <br>
>  > On Tue, Feb 8, 2022 at 12:25 AM Massimo Sgaravatto <<a href="mailto:massimo.sgaravatto@gmail.com" target="_blank">massimo.sgaravatto@gmail.com</a>> wrote:<br>
>  > Dear all<br>
>  > <br>
>  > I am running a Xena installation<br>
>  > I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administratorThis [*] is my policy.yaml file.While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended.I get this error:<br>
>  > ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673)<br>
>  > <br>
>  > Only removing the line:<br>
>  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"<br>
>  > from the policy file, I am able to resume the instance.<br>
>  > I am not able to understand what is wrong with that policy. Any hints ?<br>
> <br>
> I think we had the same conversation in June 2020 also[1].<br>
> <br>
> Nova does not restrict the policy by user_id except keypairs API. We have kept it for a few of the<br>
> destructive actions (for backwards compatibility) and intent to remove them too in future. I remember<br>
> we discussed this in 2016 but I could not find the ML thread for that but<br>
> the consensus that time was we do not intend to support user_id based restriction permission in the API.<br>
> <br>
> This is the spec where we kept the user_id support for destructive actions and the reason.<br>
> <br>
> <a href="https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html</a><br>
> <br>
> As we are moving our policy to new defaults (with new direction), after that we should discuss to remove all the user_id<br>
> enforcement support except keypair. But defiantly should not extend it for any other action.<br>
> <br>
> [1] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015273.html</a><br>
<br>
thanks i had forgot about that spec entirly.<br>
i have marked the bug as opinion and whistlist<br>
<a href="https://bugs.launchpad.net/nova/+bug/1960247" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1960247</a><br>
we can continue to disucss it but i think we would need to come to a concenus about this and given the previous spec likely<br>
treat this as a spec/feature not a bug. we certenly woudl have to consider how this woudl work with secure rbac and if this<br>
aligns with the project direction as a whole.<br>
<br>
> <br>
> -gmann<br>
> <br>
>  > Thanks, Massimo<br>
>  > <br>
>  > [*]<br>
>  > # Pause a server<br>
>  > # POST  /servers/{server_id}/action (pause)<br>
>  > # Intended scope(s): system, project<br>
>  > "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s"<br>
>  > <br>
>  > # Delete a server<br>
>  > # DELETE  /servers/{server_id}<br>
>  > # Intended scope(s): system, project<br>
>  > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"<br>
>  > <br>
>  > # Resize a server<br>
>  > # POST  /servers/{server_id}/action (resize)<br>
>  > # Intended scope(s): system, project<br>
>  > "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s"<br>
>  > <br>
>  > # Rebuild a server<br>
>  > # POST  /servers/{server_id}/action (rebuild)<br>
>  > # Intended scope(s): system, project<br>
>  > "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s"<br>
>  > <br>
>  > # Stop a server<br>
>  > # POST  /servers/{server_id}/action (os-stop)<br>
>  > # Intended scope(s): system, project<br>
>  > "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s"<br>
>  > <br>
>  > # Resume suspended server<br>
>  > # POST  /servers/{server_id}/action (resume)<br>
>  > # Intended scope(s): system, project<br>
>  > "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s"<br>
>  > <br>
>  > # Suspend server<br>
>  > # POST  /servers/{server_id}/action (suspend)<br>
>  > # Intended scope(s): system, project<br>
>  > "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"<br>
>  > <br>
> <br>
<br>
</blockquote></div>