For an user, namely "user12" who is allowed to CREATE, but not UPDATE volume metadata, as per defined in RBAC policy, the user attempt to modify existing volume metadata should fail. However, the user can modify volume metadata using either Cinder CLI or Horizon GUI, and the system will not stop it. From a hardness perspective, the Cinder backend should prevent it, in order to avoid the risk of policy violation, by intentional or unintentional misuse of the Cinder API.
Steps to Reproduce
In Horizon GUI (it fails on step 6):
1. Login as user12. Go to Project > Volumes > Volumes;
2. Ensure the ""+ New Volume"" button appears;
3. Create a new volume called volume12;
4. Make sure you can view volume12 on the list of volume and that you can see it's details by clicking on it;
5. On the "Actions" dropdown menu, click on the down arrow for volume12 and choose Update Metadata. Add a custom metadata to the volume, save;
6. Make sure you are unable to update the metadata you created or delete it
In Cinder CLI (it fails on step 3):
$ openstack volume create --image <source-image> volume12 # 1. Create volume12
$ cinder metadata volume12 set x=1 # 2. Create new volume metadata
$ cinder metadata volume12 set x=2 # 3. Update volume metadata: command should fail
Expected Behavior
After taking the steps written above, it is expected that "user12" can not update the volume metadata he/she created.
Actual Behavior
The actual behavior is that "user12" can update the volume metadata he/she created.
Reproducibility
The issue is 100% reproducible.
Solution
The following solution can be implemented by means of a patch.
In design base, both clients for Cinder CLI and Horizon GUI interface use the CREATE method from Cinder API to create and/or update volume metadata. Upon reception of the CREATE method, with a single or multiple volume metadata, Cinder shall verify whether ALL the received volume metadata is new, or whether SOME volume metadata is existing. If all volume metadata is new, Cinder shall proceed as for the handling of the CREATE method (use_create=True). Otherwise, Cinder shall proceed as for the handling of the UPDATE method (use_create=False).
Brief Description
For an user, namely "user12" who is allowed to CREATE, but not UPDATE volume metadata, as per defined in RBAC policy, the user attempt to modify existing volume metadata should fail. However, the user can modify volume metadata using either Cinder CLI or Horizon GUI, and the system will not stop it. From a hardness perspective, the Cinder backend should prevent it, in order to avoid the risk of policy violation, by intentional or unintentional misuse of the Cinder API.
Steps to Reproduce
In Horizon GUI (it fails on step 6):
1. Login as user12. Go to Project > Volumes > Volumes;
2. Ensure the ""+ New Volume"" button appears;
3. Create a new volume called volume12;
4. Make sure you can view volume12 on the list of volume and that you can see it's details by clicking on it;
5. On the "Actions" dropdown menu, click on the down arrow for volume12 and choose Update Metadata. Add a custom metadata to the volume, save;
6. Make sure you are unable to update the metadata you created or delete it
In Cinder CLI (it fails on step 3):
$ openstack volume create --image <source-image> volume12 # 1. Create volume12
$ cinder metadata volume12 set x=1 # 2. Create new volume metadata
$ cinder metadata volume12 set x=2 # 3. Update volume metadata: command should fail
Expected Behavior
After taking the steps written above, it is expected that "user12" can not update the volume metadata he/she created.
Actual Behavior
The actual behavior is that "user12" can update the volume metadata he/she created.
Reproducibility
The issue is 100% reproducible.
Solution
The following solution can be implemented by means of a patch.
In design base, both clients for Cinder CLI and Horizon GUI interface use the CREATE method from Cinder API to create and/or update volume metadata. Upon reception of the CREATE method, with a single or multiple volume metadata, Cinder shall verify whether ALL the received volume metadata is new, or whether SOME volume metadata is existing. If all volume metadata is new, Cinder shall proceed as for the handling of the CREATE method (use_create=True). Otherwise, Cinder shall proceed as for the handling of the UPDATE method (use_create=False).