FS#74489 - [swtpm] Incorrect file ownership breaks functionality

Attached to Project: Community Packages
Opened by Abdulkadir Furkan Şanlı (abdulocracy) - Sunday, 17 April 2022, 20:45 GMT
Last edited by Jonas Witschel (diabonas) - Monday, 18 April 2022, 20:08 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
The software TPM doesn't seem to work as-is due to incorrect group ownership of /var/lib/swtpm-localca.
In order to get a Windows 11 libvirt VM to pass the TPM requirement check, I had to correct the ownership with `sudo chown -R tss:root /var/lib/swtpm-localca/`


Additional info:
* version 0.7.2-1
* upstream documentation on permissions and ownership for libvirt: https://github.com/stefanberger/swtpm/wiki/Libvirt's-swtpm-configuration

Steps to reproduce:
* make a Windows 11 libvirt VM with a TPM device.
* observer the OS complain about incompatible hardware, because it cannot detect the emulated TPM.
This task depends upon

Closed by  Jonas Witschel (diabonas)
Monday, 18 April 2022, 20:08 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Directory ownership of /var/lib/swtpm-localca is set to tss:root using systemd-tmpfiles
Comment by Jonas Witschel (diabonas) - Monday, 18 April 2022, 08:07 GMT
swtpm already changes ownership of the /var/lib/swtpm-localca/ directory to tss:root using a systemd-tmpfiles configuration file: https://github.com/archlinux/svntogit-community/blob/920eace8117cdba12b2236bace7ca6ec64812e4b/trunk/PKGBUILD#L48 Since systemd-tmpfiles get executed through a pacman hook, the directory ownership should be correct right after the installation of swtpm. Indeed this is what it looks like after installing swtpm in a fresh container:

$ ls -l /var/lib/
[...]
drwxr-x--- 1 tss root 0 Mar 8 22:43 swtpm-localca
[...]

- How did file ownership look like on your system before you manually chown'ed it to tss:root?
- What happens if you remove swtpm, delete /var/lib/swtpm-localca/ if necessary, then reinstall swtpm?
- What happens if you run "systemd-tmpfiles --create" as root?
Comment by Abdulkadir Furkan Şanlı (abdulocracy) - Monday, 18 April 2022, 17:28 GMT
After reinstalling the ownership seems to allow normal functionality.

➜ sudo ls -al /var/lib/swtpm-localca
total 28
drwxr-x--- 1 tss root 230 Apr 18 19:19 .
drwxr-xr-x 1 root root 658 Apr 18 19:15 ..
-rw-r--r-- 1 tss tss 1 Apr 18 19:19 certserial
-rw-r--r-- 1 tss tss 1505 Apr 18 19:19 issuercert.pem
-rwxr-xr-x 1 tss tss 0 Apr 18 19:19 .lock.swtpm-localca
-rw-r----- 1 tss tss 8177 Apr 18 19:19 signkey.pem
-rw-r--r-- 1 tss tss 1468 Apr 18 19:19 swtpm-localca-rootca-cert.pem
-rw-r----- 1 tss tss 8180 Apr 18 19:19 swtpm-localca-rootca-privkey.pem

I can't remember exactly, but I think the directory might have been owned by tss:tss, it seems the directory needs to be tss:root, but the contents can be tss:tss to function properly.

The wiki does instruct to recursively assign ownership to tss:root, I'm not sure what's up with that.
Comment by Jonas Witschel (diabonas) - Monday, 18 April 2022, 20:07 GMT
I think tss:tss instead of tss:root should be fine as well, if anything that would allow for more access instead of less (to users in the tss group other than the tss user).

I can think of two things that might have gone wrong: either systemd-tmpfiles failed to run (e.g. due to an aborted pacman update) and the directory ownership stayed at the default root:root, or libvirt ran swtpm_setup as the wrong user. Neither are packaging problems related to swtpm, so I am going to close this issue for now.

Loading...