Bug: cockpit / virtd / libvirt-qemu tries to change chown of local ISO images

[cookiengineer]

Explain what happens

1. Create a new virtual machine
2. Local install media
3. Use a path where owner is the login user (e.g. /home/user/Downloads/iso_image.iso)
4. It will fail with a generic error message that cannot read the image file
5. ls -la /home/user/Downloads output will be afterwards (same error happened with trisquel before in my case):

> ls -la
total 9702452
drwxrwxrwx  2 cookiengineer users              4096 May  4 12:37 .
drwxr-xr-x 11 cookiengineer users              4096 May  4 12:46 ..
-rwxrwxrwx  1 libvirt-qemu  libvirt-qemu 2698809344 May  4 12:37 GhostBSD-24.01.1.iso
-rwxrwxrwx  1 cookiengineer users        4556818432 Apr 28 11:25 openKylin-1.0.1-x86_64.iso
-rwxrwxrwx  1 cookiengineer users        2614644736 Apr 28 11:25 redstar_desktop3.0_sign.iso
-rwxrwxrwx  1 libvirt-qemu  libvirt-qemu   65011712 Apr 28 08:23 trisquel-netinst_11.0_amd64.iso

What I would expect is that read rights are enough, and that libvirt-qemu should not try to assign a different chown user when using a local install media. I'm not sure whether there's a flag or config for virtd, but this was the problem in my case why no installation succeeded.

When I was using a different folder (e.g. in /tmp/whatever) where the user libvirt-qemu owned the folder itself, it worked.

It also seems that for whatever reason, the selected iso image folder (used via auto-complete in the input textarea in the Cockpit Create VM UI dialog) gets a 0777 chmod, which I think is bad practice because it can potentially fuckup the filesystem rights and make malware/other binaries executable which shouldn't be executable.

Version of Cockpit

315-2

Where is the problem in Cockpit?

None

Server operating system

None

Server operating system version

Arch Linux (updated 2024-05-03)

What browsers are you using?

Firefox, Chrome

System log

No response

[martinpitt]

Supposedly you were trying to run a system VM, instead of a user one? The system libvirt runs as user "libvirt", not root. Likely your /home/user isn't accessible by other users, in particular not libvirt.

Note that files in user home directories are not supported at all for the system instance on e.g. Fedora or RHEL: SELinux just forbids that. Similarly on Debian/Ubuntu with AppArmor. system images need to be in /var/lib/libvirt/images/.

$ touch fake.iso
$ ls -l fk
$ ls -l fake.iso 
-rw-r--r--. 1 admin admin 0 May  5 02:16 fake.iso

$ sudo virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk fake.iso --wait 0 --name test1
ERROR    internal error: process exited while connecting to monitor: 2024-05-05T02:16:49.245194Z qemu-system-x86_64: -blockdev {"driver":"file","filename":"/home/admin/fake.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}: Could not open '/home/admin/fake.iso': Permission denied

That's because the libvirt user cannot access /home/admin, both due to SELinux and also because home directories are not readable/accessible by other users (it's 0700 permissions). When I disable SELinux and do chmod go+rx ~ it does work, so it's likely that this is the case for you as well.

cockpit-machines itself doesn't chmod/chown anything, it's virt-install which does that. After the above virt-install command, the file gets chowned:

-rw-r--r--. 1 qemu qemu 0 May  5 02:16 fake.iso

This is on Fedora, Arch seems to name the user "libvirt-qemu", but same difference.

So this isn't actionable from c-machine's PoV. Feel free to send a bug against virt-install about not chowning files, but it's a bit of a "you asked for it, you got it" case I think..