Is it possible to deploy lxc container through the API with bind mounts?

[RandyT]

I'm attempting to deploy lxc containers through the API and have run into an error that tells me that only root@pam is allowed to create mount point type bind. I've compared permissions to the API token I am using and am not really seeing anything that stands out as the missing permissions I have assigned to the token id.

Is it possible to deploy an lxc container through the API with bind mounts (without doing it as root@pam)?

 

[fabian]

no - that feature is intentionally restricted since it allows access to arbitrary host paths.

 

[RandyT]

What type of filesystem do you recommend using to share between containers that is performant and can be deployed through the API?

I would respectfully request that this be a configurable security feature. I control my entire environment and would prioritize the ability to create bind mounts through the API over the security of not being able to.

 

[fabian]

you can - you just have to use the root@pam user.

there are two features that would solve your issue:
- superuser "privilege": https://bugzilla.proxmox.com/show_bug.cgi?id=2582 (with the downside that this would still allow more than just bind mounts)
- admin defined bind mounts (similar to hardware pass through - admin sets up host paths that can be bind-mounted, and can then hand out access to that defined entity so regular users/tokens can add them to guests)

 

[RandyT]

Thanks for the quick reply @fabian, Can you point to any docs or examples of the second option for "admin defined bind mounts"?

Searching I am finding discussions on this point (many with you involved in the discussion many years ago. ) but not finding anything on the concept of admin defined.

I'm attempting to do this via Terraform FWIW but running into the error regarding root@pam.

 

[fabian]

it's something that is planned, not something that exists already it's the same issue with hardware pass through (USB/PCI), where some preliminary patches have been applied, but the bulk is still being worked on.

 

[RandyT]

Sorry to be dense about this but I'm finding that even if I create an API token for root@pam with Administrator privileges, I'm unable to create the bind mount. Getting 403 from the API.

 

[fabian]

yes, you need the root@pam user. an API token is a separate entity (with possibly vastly reduced privileges), so it can't be treated identical. all the "root-only" checks are currently not handled like regular privilege checks (changing that is what the linked bug is about), but are really checking for the actual and only "root@pam" user.

 

[RandyT]

I see, so no authentication using API token. Must use user/password.

 

[fabian]

yes, unfortunately required for the time being for certain root-only features.

 

[SergiuCC]

Hello, I'm having the same issue when using Terraform or Ansible is there a way or plans to allow more actions for a "user with token" or it MUST be the root? I'd like to keep that user using MFA and not being involved in doing any of the automation?

 

[fabian]

if it is just for bind mounts, then the dir mapping feature: https://lists.proxmox.com/pipermail/pve-devel/2023-November/059863.html which is being worked on can be extended for containers as well to allow "managed bind mounts", where a highly privileged user sets them up, and lesser privileged users can be given access to use those host dirs in guests.

 

[SergiuCC]

Thank you @fabian that's indeed a great news! Yes, I think that should do it, as I'm looking to mount an SMB/NFS mount to my container so I can store some of the config files.