Comment 205 for bug 2004555

Reviewed: https://review.opendev.org/c/openstack/cinder/+/882837
Committed: https://opendev.org/openstack/cinder/commit/cb4682fb836912225c5da1536108a0d05fd5c46e
Submitter: "Zuul (22348)"
Branch: stable/zed

commit cb4682fb836912225c5da1536108a0d05fd5c46e
Author: Gorka Eguileor <email address hidden>
Date: Thu Feb 16 15:57:15 2023 +0100

    Reject unsafe delete attachment calls

    Due to how the Linux SCSI kernel driver works there are some storage
    systems, such as iSCSI with shared targets, where a normal user can
    access other projects' volume data connected to the same compute host
    using the attachments REST API.

    This affects both single and multi-pathed connections.

    To prevent users from doing this, unintentionally or maliciously,
    cinder-api will now reject some delete attachment requests that are
    deemed unsafe.

    Cinder will process the delete attachment request normally in the
    following cases:

    - The request comes from an OpenStack service that is sending the
      service token that has one of the roles in `service_token_roles`.
    - Attachment doesn't have an instance_uuid value
    - The instance for the attachment doesn't exist in Nova
    - According to Nova the volume is not connected to the instance
    - Nova is not using this attachment record

    There are 3 operations in the actions REST API endpoint that can be used
    for an attack:

    - `os-terminate_connection`: Terminate volume attachment available at
    - `os-detach`: Detach a volume
    - `os-force_detach`: Force detach a volume

    In this endpoint we just won't allow anything that is not coming from a
    service. This should not be a problem because:

    - Cinder backup doesn't use the REST API but RPC calls via RabbitMQ
    - Glance doesn't use this interface

    Checking whether it's a service or not is done at the cinder-api level
    by checking that the service user that made the call has at least one of
    the roles in the `service_token_roles` configuration. These roles are
    retrieved from keystone by the keystone middleware using the value of
    the "X-Service-Token" header.

    If Cinder is configured with `service_token_roles_required = true` and
    an attacker provides non-service valid credentials the service will
    return a 401 error, otherwise it'll return 409 as if a normal user had
    made the call without the service token.

    Closes-Bug: #2004555
    Change-Id: I612905a1bf4a1706cce913c0d8a6df7a240d599a
    (cherry picked from commit 6df1839bdf288107c600b3e53dff7593a6d4c161)
    Conflicts:
            cinder/exception.py
    (cherry picked from commit dd6010a9f7bf8cbe0189992f0848515321781747)