Hello there!
After some days of googling and reading discussions I could not find anything to solve my issue, starting to doubt I might have used wrong terminology to search (not unlikely) I decided to ask in a specific thread.
Apologies in advance if this is a duplicate, wrong subforum or if I didn't understand some core design patterns for which my question is totally pointless.
I have a cluster and one node of this cluster can be accessed by a user in the PVE realm with specific permissions to certain VMs residing there. I achieved this by granting the most granular privileges possible (to my knowledge) by creating a custom role with following perms:
This user, among other operations, should be able to perform memory dumps of the specific VMs and save it somewhere locally on the VM using Proxmox python API wrapper (proxmoxer(not so latest version)). In order to do this, I found 2 VM.Monitor commands that might do the trick dump-guest-memory and memsave, but both need a path to save the file which would require Sys.Admin privilege which I would gladly avoid. The final goal would be to have the memdump on the VM filesystem from which the code executed.
To workaround the 403 issue, I created a new storage Directory in the Datacenter, exclusive to the node and pointed to a folder in /opt/. Then I gave my user permission on this new storage but the problem still persists. I am starting to think this user resides in the wrong realm and doubting about the feasibility of what I want to do from the PVE realm. I am fine to store the memdumps somewhere on the VM from which the APIs execute the monitor commands but I am at a loss on how to do that without passing through the host filesystem on which I can't chown/chmod since the target user is not PAM.
edit: I would also like to avoid duplicating the user in the PAM realm for security reasons
I tried to be as clear as I can but I'm still in a learning phase and not a native speaker so please be understanding.
Thanks for the help.
After some days of googling and reading discussions I could not find anything to solve my issue, starting to doubt I might have used wrong terminology to search (not unlikely) I decided to ask in a specific thread.
Apologies in advance if this is a duplicate, wrong subforum or if I didn't understand some core design patterns for which my question is totally pointless.
I have a cluster and one node of this cluster can be accessed by a user in the PVE realm with specific permissions to certain VMs residing there. I achieved this by granting the most granular privileges possible (to my knowledge) by creating a custom role with following perms:
Code:
VM.Config.Options, VM.Console, VM.Config.Network, VM.Audit, VM.Snapshot, VM.Allocate, VM.Clone, VM.Monitor, VM.PowerMgmtThis user, among other operations, should be able to perform memory dumps of the specific VMs and save it somewhere locally on the VM using Proxmox python API wrapper (proxmoxer(not so latest version)). In order to do this, I found 2 VM.Monitor commands that might do the trick dump-guest-memory and memsave, but both need a path to save the file which would require Sys.Admin privilege which I would gladly avoid. The final goal would be to have the memdump on the VM filesystem from which the code executed.
To workaround the 403 issue, I created a new storage Directory in the Datacenter, exclusive to the node and pointed to a folder in /opt/. Then I gave my user permission on this new storage but the problem still persists. I am starting to think this user resides in the wrong realm and doubting about the feasibility of what I want to do from the PVE realm. I am fine to store the memdumps somewhere on the VM from which the APIs execute the monitor commands but I am at a loss on how to do that without passing through the host filesystem on which I can't chown/chmod since the target user is not PAM.
edit: I would also like to avoid duplicating the user in the PAM realm for security reasons
I tried to be as clear as I can but I'm still in a learning phase and not a native speaker so please be understanding.
Thanks for the help.
Last edited: