terraform-provider-libvirt icon indicating copy to clipboard operation
terraform-provider-libvirt copied to clipboard

Permission denied at VM create on remote KVM with non-root user

Open mocart2 opened this issue 2 years ago • 9 comments

System Information

Linux distribution

Ubuntu 22.04 amd64

Terraform version

Terraform v1.2.9
on linux_amd64

Provider and libvirt versions

.terraform/providers/registry.terraform.io/dmacvicar/libvirt/0.7.1/linux_amd64/terraform-provider-libvirt_v0.7.1

Checklist

  • [ ] Is your issue/contribution related with enabling some setting/option exposed by libvirt that the plugin does not yet support, or requires changing/extending the provider terraform schema?

    • [ ] Make sure you explain why this option is important to you, why it should be important to everyone. Describe your use-case with detail and provide examples where possible.
    • [ ] If it is a very special case, consider using the XSLT support in the provider to tweak the definition instead of opening an issue
    • [ ] Maintainers do not have expertise in every libvirt setting, so please, describe the feature and how it is used. Link to the appropriate documentation
  • [x] Is it a bug or something that does not work as expected? Please make sure you fill the version information below:

Description of Issue/Question

Setup

I use alias to connect remote KVM server and use non-root ubuntu(with sudo no passwd all) user:

provider "libvirt" {
  uri = "qemu:///system"
}

provider "libvirt" {
    alias = "core"
    uri   = "qemu+ssh://[email protected]/system?keyfile=/root/.ssh/ubuntu&known_hosts_verify=ignore"
}

Steps to Reproduce Issue

connect to remote KVM is good, but when TF creates libvirt domain i have error: error on localhost:

Error: error creating libvirt domain: Cannot access storage file '/data/vms/admintestvm/admintestvm-root' (as uid:64055, gid:108): Permission denied
│
│   with module.vm.libvirt_domain.vm[0],
│   on .terraform/modules/vm/main.tf line 47, in resource "libvirt_domain" "vm":
│   47: resource "libvirt_domain" "vm" {

tf debug on localhost:

2023-07-20T22:15:36.117Z [ERROR] provider.terraform-provider-libvirt_v0.7.1: Response contains error diagnostic: tf_provider_addr=provider tf_resource_type=libvirt_domain tf_rpc=ApplyResourceChange @caller=github.com/hashicorp/[email protected]/tfprotov5/internal/diag/diagnostics.go:55 diagnostic_detail= diagnostic_severity=ERROR diagnostic_summary="error creating libvirt domain: Cannot access storage file '/data/vms/admintestvm/admintestvm-root' (as uid:64055, gid:108): Permission denied" tf_proto_version=5.3 tf_req_id=266459ac-d72e-a0ec-1fa9-de27d372376f @module=sdk.proto timestamp=2023-07-20T22:15:36.117Z
2023-07-20T22:15:36.118Z [ERROR] vertex "module.vm.libvirt_domain.vm[0]" error: error creating libvirt domain: Cannot access storage file '/data/vms/admintestvm/admintestvm-root' (as uid:64055, gid:108): Permission denied

2023-07-21T06:08:48.198Z [INFO]  provider.terraform-provider-libvirt_v0.7.1: 2023/07/21 06:08:48 [DEBUG] cleaning up connection for URI: qemu+ssh://[email protected]/system?keyfile=/root/.ssh/ubuntu&known_hosts_verify=ignore: timestamp=2023-07-21T06:08:48.198Z

after i get error, i checked dir based storage pool permissions on remote KVM:

root@core:/data/vms# ls -lth
total 4,0K
drwx--x--x 2 root root 4,0K июл 21 06:08 admintestvm

root@core:/data/vms/admintestvm# ls -lth
total 625M
-rw-r--r-- 1 root root 194K июл 21 06:08 admintestvm-root
-rw-r--r-- 1 root root 366K июл 21 06:08 commoninit.iso
-rw-r--r-- 1 root root 625M июл 21 06:08 ubuntu-jammy
root@core:/data/vms/admintestvm# groups ubuntu
ubuntu : ubuntu adm cdrom sudo dip plugdev libvirt

so, i seen, TF creates VMs dir by root (but i connect to remove KVM with ubuntu user) and write permissions only root user, why?

p.s. when i use root user on connection string - i haven't problems.


Additional information:

Do you have SELinux or Apparmor/Firewall enabled? Some special configuration? First of all, i read README.md and:

  1. remove apparmor from my remote KVM server
  2. Add libvirt non-root user (before install KVM)
  3. Enable libvirt group in /etc/libvirt/libvirtd.conf
root@core:/data/vms# cat /etc/libvirt/libvirtd.conf | grep -i unix_sock_group
unix_sock_group = "libvirt"
  1. Set the UNIX socket permissions for the R/W socket in /etc/libvirt/libvirtd.conf
root@core:/data/vms# cat /etc/libvirt/libvirtd.conf | grep -i unix_sock_rw_perms
unix_sock_rw_perms = "0770"
  1. disable security driver:
root@core:/data/vms# cat /etc/libvirt/qemu.conf | grep -i security_driver
#       security_driver = [ "selinux", "apparmor" ]
# value of security_driver cannot contain "dac".  The value "none" is
# a special value; security_driver can be set to that value in
security_driver = "none"
  1. And restart systemctl restart libvirtd

Have you tried to reproduce the issue without them enabled? yes

mocart2 avatar Jul 21 '23 06:07 mocart2

Same issue here. Issue persists even when using a root user on the qemu ssh connection string. The disk file on disk has the correct permissions and ownership, same as all of the others on the pool (pre-existing default pool at /var/lib/libvirt/images).

luispabon avatar Jan 30 '24 10:01 luispabon

I am seeing this as well. Has anyone found a workaround at least for now?

bmeyer71 avatar Apr 24 '24 18:04 bmeyer71

Maybe this thread would help, I experienced a similar issue and setfactl -m helped me. See below: https://www.linux.org/threads/kvm-machine-doesnt-start-due-to-permissions.44566/post-188884

laszlo-gyulai avatar Jun 17 '24 14:06 laszlo-gyulai

Maybe this thread would help, I experienced a similar issue and setfactl -m helped me. See below: https://www.linux.org/threads/kvm-machine-doesnt-start-due-to-permissions.44566/post-188884

I've actually tried something similar by just granting libvirt-qemu full control of the path. But that didn't make a difference. The thing that is odd, I can use Virtual Machine Manager to connect to the remote host and it will create the VM without any issues. The file permissions are set correctly as well.

bmeyer71 avatar Jun 19 '24 15:06 bmeyer71