Closed UAnton closed 7 years ago
This is the point of being Operator on a SR, you can remove VDIs (but not the SR itself). It would be a bug if we got ACLs on the VDI level, which we don't.
If you want your user to create disks or snapshots on a SR, you need to give them rights to do so. And because we don't have ACLs on VDI, that's coherent they can remove VDIs on this SR.
Possibilities:
Creating VDI ACLs is more tricky, but doable. In fact, it's in the TODO list, because if it wasn't a big deal before self-service, it's more annoying now.
We have now to decide what is the best way to do that. Here is some questions:
It's a kind of "policy" which change from all previous 3 roles (read: only view, operator: edit the object, admin: remove the whole object). I'm open to ideas to keep the same principle.
I need time to think about it ...
Maybe remove SR from list in user interface but keep permissions? User Can see\export\delete snapshot in VM interface.
Just removing the view is not really a security, but it could be acceptable if there isn't other cases where user actually need to operate VDIs on SR.
Remember the consequences of creating snapshots or VDIs on a SR: it consumes disk space, so you need to give rights carefully anyway.
In some cloud control systems I saw limit the number of snapshots. If you can restrict vCPUs, storage capacity and memory? Maybe you can restrict number of snapshots?
Perhaps it's a way, but snapshots diff can grow with time, so it's hard to be sure about the maximum space really used for a user.
This is a tricky question. I'll also discuss with @julien-f about this.
Also a very strange place "Copy the VM". The users not have permissions for local storages , but can copy his VMs to all stores in the pool. Migrate VM - The user should not be allowed to Migrate VMs! We need to think how to fix it.
We got users asking for migrate VMs, and this is only possible if you have rights on other hosts (otherwise, you shouldn't see any available servers).
Should be the same for copy in theory. If not, open another issue.
Any news?
That's not something we could fix instantly. I fixed the copy VM and migrate for 4.15.1.
But we currently didn't find a solution satisfying solution for ACLs... I'm open to ideas :)
Ok, I'm think about possible solutions...
Hello.
It seems that we have two possible improvements for Xen orchestra:
Anyway, we guess that it is very important that you will hide interface of storage management from non-privileged users.
The total disk space is already limited at the self-service level.
Limiting snapshots won't change anything: you need to get the right to "write" on the SR. But today, the right to write is also the right to read and write on the whole object (SR). This is the thing we need to modify/enhance.
But space does not limited to snapshots. I create resourse 4Gb HDD and create VM with 4GB HDD. Now I created 25 snapshots and use 6GB but have limit 4GB.
The original issue was about possibility to make snapshots without having Operator rights on the SR. Because an operator can remove everything on the SR, people ask a way to make snapshots without having the "real" Operator right.
About the other issue (creating snapshots): we only make limitation during the VM creation, not after.
Create permission "Snapshot" but don't add SR to user UI. P.S. Temporary solution
Hi! Do you have Any new solutions?
@julien-f what should we do about that?
It's normal for an SR operator to be able to delete VDIs.
I think your usage issues will be fixed by self service improvements.
BUG User can delete snapshots and disks from SR with "Operator" permissions.
Description: