A Question - VM.Backup Role Permission Issue

[FormerVMW]

Hello,

I'm getting my first proxmox system online (Broadcom/VMware victim). I'm quite impressed thus far with the ease of pulling in VMs from VMware systems and the setup/performance compared to VMware.

Anyways, I had a quick question:

I created a very basic role that includes: VM.Audit VM.Config VM.CDROM VM.Console VM.Monitor VM.PowerMgmt VM.Snapshot VM.Snapshot.Rollback. As a user with these permissions, if I click on Backup I'm presented with the Backup screen and the "Backup Now" button. If the "Backup Now" button is pressed it freezes the browser with a "please wait" screen. The only way out of it is to refresh the browser. I'm assuming this is normal. If this is normal, shouldn't the user (without VM.Backup) be prevented from getting into this situation in the first place? e.g. No ability to enter the backup section or simply not able to click "Backup Now".

 

[Hqu]

Hey,

you need to add a backup target where you can backup your VMs to.

1. You missing a backup datastore (here you can use Proxmox Backup Server)
2. Your backup user need the build-in role PVEDatastoreUser which points to the backup target/datastore

Let me know if that works for you

Best

 

[FormerVMW]

Hey,

you need to add a backup target where you can backup your VMs to.

1. You missing a backup datastore (here you can use Proxmox Backup Server)
2. Your backup user need the build-in role PVEDatastoreUser which points to the backup target/datastore

Let me know if that works for you

Best

Hi, I do not want the user to have backup access. Thus why the role did not include VM.Backup.

 

[fabian]

could you please double check your permission settings? for me, if I configure a user with the privileges you mention, the backup tab is not even displayed in the first place..

 

[FormerVMW]

could you please double check your permission settings? for me, if I configure a user with the privileges you mention, the backup tab is not even displayed in the first place..

Hi, the role has: VM.Audit VM.Config.CDROM VM.Console VM.Monitor VM.PowerMgmt VM.Snapshot VM.Snapshot.Rollback

A user named testuser, with role "TESTROLE" has been assigned permissions on a VM.

See screenshots. I can access backup and click "Backup now".

I created this for a second time, with the same results, as a sanity check.

 

[fabian]

tried the same, still not there please post your user.cfg and the output of "pveum user permissions 'testuser@pve'" (and maybe also try force-reloading your browser window just for good measure).

 

[FormerVMW]

Hi, all testing was done via Edge and all work on Promox itself (as root) done via Brave.

As for the outputs:

root@pve:~# pveum user permissions 'testuser@pve'
┌──────────┬──────────────────────────┐
│ ACL path │ Permissions │
╞══════════╪══════════════════════════╡
│ /vms/100 │ VM.Audit (*) │
│ │ VM.Config.CDROM (*) │
│ │ VM.Console (*) │
│ │ VM.Monitor (*) │
│ │ VM.PowerMgmt (*) │
│ │ VM.Snapshot (*) │
│ │ VM.Snapshot.Rollback (*) │
├──────────┼──────────────────────────┤
│ /vms/103 │ VM.Audit (*) │
│ │ VM.Backup (*) │
│ │ VM.Config.CDROM (*) │
│ │ VM.Config.Cloudinit (*) │
│ │ VM.Console (*) │
│ │ VM.PowerMgmt (*) │
└──────────┴──────────────────────────┘
Permissions marked with '(*)' have the 'propagate' flag set.

user.cfg attached. Identifying information crossed out.

 

[FormerVMW]

Okay, I "fixed" it. I removed the permissions on /vms/103 and it stopped allowing me access to backup (and other things) on /vms/100.

Is this normal? If so, can you point me in the direction of instructions on how to provide different levels of access to different VMs? Same user, but different role on different VMs.

 

[Hqu]

You can create different Roles for different Permissions and assign them to the User Permission required VMs/LXCs -

1. Datacenter > Permissions > Roles
2. Datacenter > Permissions > Users

https://pve.proxmox.com/wiki/User_Management#pveum_permission_management

Best

 

[fabian]

you did it right (your user doesn't have backup permissions for that guest!) - it's just that the GUI doesn't have a detailed view of the server-side permissions, but just a "broad" one (that is calculated server-side upon login, and then refreshed with each session ticket refresh every few minutes).

so in your case, the combination of:

- user has VM.Backup on some guest (which enables the backup parts of the GUI)
- user lacks permissions on any storage (which breaks the backup parts of the GUI)

is the culprit! the latter should of course be fixed, the former is a bit harder/extensive work, but planned as well.

 

[FormerVMW]

you did it right (your user doesn't have backup permissions for that guest!) - it's just that the GUI doesn't have a detailed view of the server-side permissions, but just a "broad" one (that is calculated server-side upon login, and then refreshed with each session ticket refresh every few minutes).

so in your case, the combination of:

- user has VM.Backup on some guest (which enables the backup parts of the GUI)
- user lacks permissions on any storage (which breaks the backup parts of the GUI)

is the culprit! the latter should of course be fixed, the former is a bit harder/extensive work, but planned as well.

Hi Fabian,

Can we go back to this topic for a little bit?

I created a test user and assigned him the pre-made set of permissions: PVEVMUser

When I login as the user I have all the permissions that I should have and I can go to the backup section but I can't see any of the backups because I can't select any storage.

My dumps are located on a Datastore named: "NFS". The backups became visible after I added permissions on NFS to the test user using the predefined permissions: PVEDatastoreUser.

That seems fine because access to storage is a different set of permissions. Am I missing something or is this the proper way that it should be done? I realize I should be doing group access on the datastore to make it more streamlined.

Feature request: It would be great to have more control of the functionality of each permission granted. For example, I'd like users to see their backups, but not be able to delete them. They exist, they can see them, but they can't destroy them. Destroying backups seems like it should be more of an Admin function. The same case could be made for Backup now, but it's not as extreme as having the ability to remove backups.

 

[fabian]

we might at some point offer more fine-grained permissions there (like we do in PBS), but changing such fundamental aspects needs to be done with a major release. it is also often problematic to allow users to do an action, but not undo it, so usually a permission to "Allocate" something (a guest, a disk, a backup archive,..) also entails removing the same thing again, with a lower privilege level allowed to change/configure ("Modify"), but not allocated or delete, and an even lower privilege level to "see", but not change ("Audit"). for storage we have the distinction of Allocate (create new storages, delete them, re-configure them, but also do basically any operation on its contents), AllocateSpace (create/delete volumes, sometimes with additional pre-conditions required) and AllocateTemplate (for downloading/uploading isos, CT template archives, .. or removing them).

for backups in particular, I can see how allocating, but not removing makes sense (see PBS ), it's just not that easy to add to the existing PVE scheme without adding one-off privileges, which we try to avoid. if you are using PBS, you can configure the PBS storage on the PVE side with a token that can not delete anything on the PBS side though, getting the same effect although with slightly worse UX, since PVE is not aware that the PBS storage is non-prunable.

 

[FormerVMW]

Yes, I agree the more granularity/specificity added... the more complexity.

The PBS solution seems the best option in this case.

Thanks for mentioning it as we are a week or two out from deploying it and that appears to resolve this issue.

Thank you for your response.