How to reduce permissions to object path?

[Gendolph]

On Proxmox 6.1-5 I have group with PVEVMAdmin role.

All VMs are manager by user of this group well. But I want to restrict permissions for some VMs. So, I added those VMs to pool (all other VMs are not in any pool) and set role PVEVMUser to pool's object path.

My permissions looks like:
Path - Group - Role - Propagation

/ - MyGrp - PVEVMAdmin - true
/pool/MyPool - MyGrp - PVEVMUser - true

But users of the group still may remove VMs of the pool.

I suppose that permissions of root object (PVEVMAdmin) is not reduced for /pool/MyPool object path to PVEVMUser.
The same behaviour is in case if I change root path (/) to all VMs path (/vms).

How to reduce permissions for pool's VMs?

 

[wolfgang]

Hi,

there is no single permission that handle this.

You can create a new rule without

VM.Allocate: create/remove new VM to server inventory
Datastore.Allocate: create/remove/modify a data store, delete volumes

 

[Gendolph]

Hi, Wolfgang. Thanks for your reply.

Of course, PVEVMUser role that I use for group for pool has not these permissions. It is what I want.
But if I remove VM.Allocate from PVEVMAdmin role, users will not allowed to create VMs.

My goal is to allow users to fully manage all VMs (PVEVMAdmin) that are not in the pool AND only view&powerMng (PVEVMUser is ok) VMs of the pool.

 

[fabian]

pool ACLs don't have precedent over regular ones, so this is not possible with pools. the ACL resolver does the following, given a user and path as input:

1. iterate over paths starting at '/'
2. check if a user ACL matches for the current user => if true, remember result, continue to next path
3. check if a group ACL matches => if true, remember result

now you have a list of roles that this user has (either directly, or via a group) on your given path. user has precedence over group, and more specific paths over broader paths.

next, we calculcate pool roles:

1. iterate over all pools
2. check roles current user has on pool
3. remember roles for all pool member guests and storages

now you merge the results from these two steps, but the former has precedence.

during this whole process, NoAccess is handled in a special way, since it neutralizes any other roles the user might have. you either need to turn your scheme around (give PVEVMUser by default, and PVEVMAdmin for a special pool) or if the guests you want to limit further are only a few and fairly static, you can setup individual ACLs for them that would overwrite those set up for /vms.

this is quite tricky to change, since pools sit somewhere inbetween general path with propagation and specific leaf paths, but all of those are handled in a single step and the pools later on (the ACL resolution is agnostic to what a path represents, or whether it's a leaf path or not). the ability to override pool ACLs with specific ones is more important than the ability to override general propagated ACLs with pool ACLs.

 

[Gendolph]

Hi, Fabian. Thanks for you answer.

Ok, this is not possible to solve my problem by the way I'm trying.
But I can create another pool (UserPool) and move all VMs to this one. Also set role PVEVMAdmin to the UserPool and PVEVMUser to old pool (let's name it AdminPool).
Now it works as I want.

But I have little inconvenience: each time user creates a VM it should change pool from empty to UserPool. And if it forgot to do this at first step of VM creation, it will get an error later (because have access only to UserPool).

Is it possible to set default pool for group users (or to all users of cluster, no matter)? Or may be restrict users to create VMs outside any pool (suppose any allowed pool will be selected by default on first step of VM creation)?

 

[fabian]

But I have little inconvenience: each time user creates a VM it should change pool from empty to UserPool. And if it forgot to do this at first step of VM creation, it will get an error later (because have access only to UserPool).

Is it possible to set default pool for group users (or to all users of cluster, no matter)? Or may be restrict users to create VMs outside any pool (suppose any allowed pool will be selected by default on first step of VM creation)?

no, that is not possible within the current model.