Comment 8 for bug 1968131

I found it in ps
4 113 1814 758 20 0 13772 5784 - S ? 0:00 \_ /usr/bin/swtpm_setup --tpm2 --tpm-state /var/lib/libvirt/swtpm/202a34a9-2ee2-4826-b206-c249f535be90/tpm2 --vmid testguest:202a34a9-2ee2-4826-b206-c249f535be90 --logfile /var/log/swtpm/libvirt/qemu/testguest-swtpm.log --createek --create-ek-cert --create-platform-cert --lock-nvram --not-overwrite

That 113 is swtpm

$ id 113
uid=113(swtpm) gid=121(swtpm) groups=121(swtpm)

In swtpm itself the executing user/group was changed (see the already referenced mir bug) to be more secure. The biggest remaining difference here vs the working execution with root is that user/group.

We have adopted that behavior as requested by Steve in bug 1948880.
In fact without 1948880 due to the respective user/group change in the swtpm package we encountered the very same issue we see now - and it was resolved by that upload.

Maybe the updates to libtpms/swtpm since then (or anything else) makes it use different directories now.

Changing the user libvirt uses to spawn swtpm indeed changes the behavior.
It now ends like:
  Need read rights on signing key /var/lib/swtpm-localca/signkey.pem for user swtpm.
  swtpm-localca exit with status 1:
  An error occurred. Authoring the TPM state failed.

That at least confirms that we seem to be on the right track.

For further tests we'll likely need to purge swtpm + some directories, reinstall it and retry from there. To ensure nothing is just based on former file ownership.