[SOLVED] ACLs with pmxcfs (/etc/pve)

[SacredSheep]

Hi,

I am trying to figure out how/if it's possible to use ACLs for the proxmox FUSE-based file system mounted unter /etc/pve.

https://pve.proxmox.com/pve-docs/chapter-pmxcfs.html
just says "You can’t change file permissions (permissions are based on paths)"

A bit more context of why I am asking this, as maybe there is another way to achieve what I want:
I want to write VM config files under /etc/pve/qemu-server via Ansible. As the Ansible will be executed in a Gitlab Runner, and security is a concern, I don't want it to have ssh root access to the proxmox host. So I want to set up a user who is only allowed to write to /etc/pve/qemu-server. But this does not seem to be possible with pmxcfs?
It would already help if I could restrict a non-root user with write the whole /etc/pve fuse mount, even if more granular rules are not possible.

Thank you for any advice or help.

 

[cheiss]

Hi,

I want to write VM config files under /etc/pve/qemu-server via Ansible.

this seems rather a bit backwards. Is there a particular reason why you cannot you the API directly, or through some (community) Ansible module like e.g. community.general.proxmox?

That way you can simply use an API token with the correct, restricted permission set, relying on the API for proper permission enforcement.

 

[SacredSheep]

So, there are two main reasons for wanting to do it this way:

• some settings for KVM based VMs can seemingly not be done via GUI or API. (I am waiting for feedback for which in particular)
• customer request

 

[cheiss]

some settings for KVM based VMs can seemingly not be done via GUI or API. (I am waiting for feedback for which in particular)

What setting would that be? Everything should be doable via API (the GUI and CLI use exactly that APi, so if it can be done via GUI/CLI than definitely).

• customer request

And does that customer have a particular reason for it? Seems more like a "last-resort" type of thing, a workaround - not a solution to a problem.

In any case, pmxcfs (and esp. /etc/pve) is no ordinary file system as you already discovered. Being able to change permissions could yield all sort of problems. Handling permissions on the file-level must be done with care - that's why /etc/pve is restricted to the superuser/privileged API daemon.

So really, no, that's not possible AFAIK.

 

[SacredSheep]

Thank you for the feedback so far.

So, the customers claim is that it's not possible to set a fake/custom WWN for the Volumes when creating a VM via API.
But https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/qemu/{vmid}/config suggests that I can in fact specify a Volume WWN at VM creation. Am I looking at the correct API endpoint for that?

Their other reason is, that they want a declarative way of specifying the VMs (i.e. VM config files written via CICD regularily to overwrite any manual changes to the VMs).

 

[cheiss]

But https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/qemu/{vmid}/config suggests that I can in fact specify a Volume WWN at VM creation. Am I looking at the correct API endpoint for that?

Yes, that's correct. You can e.g. also test this very easily by using qm set 100 -scsi0 local-lvm:16,wwn=0x5002e10000000000, which would create a new SCSI disk with 16 GiB and the specified (fake) WWN.
Via the API it works pretty much the same, qm uses it the under the hood too.

Their other reason is, that they want a declarative way of specifying the VMs (i.e. VM config files written via CICD regularily to overwrite any manual changes to the VMs).

You could either convert these config files to an API call (even something simple like using curl) or generate these API calls directly, if possible. That would be the proper way, at least.

Writing these configuration files directly also circumvents the whole PVE stack, so there cannot be really made any guarantee that it will work. That's what the API is for, for which we take great care to preserve backwards-compatibility.

 

[SacredSheep]

Thanks a lot so far, this is very helpful.

I noticed that the assigned WWN get's lost whenever the disk is detached from the VM. I can specify it when reattaching the disk via CLI, but is there a way for the disk to keep the WWN even when in detached state?

(This moved away from the original topic of the thread, please let me know if I should create a new thread instead.)

 

[cheiss]

I noticed that the assigned WWN get's lost whenever the disk is detached from the VM. I can specify it when reattaching the disk via CLI, but is there a way for the disk to keep the WWN even when in detached state?

No, that is unfortunately not possible. For detached disks, only the actual reference to the disk on the storage is kept, nothing more.
So you would have to - depending on the details - implement that yourself.

You could maybe (ab-)use the description property for that, i.e. when detaching a disk (via the API, assuming here) save the original `scsiN` (or whatever) configuration in there. Bit hacky, but would save you from having to store that somewhere else.