On Tue, 24 Jun 2025 09:12:33 +0100
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
On Tue, Jun 24, 2025 at 01:25:47PM +0530, Aithal, Srikanth wrote:
> libguestfs: command: run: \ --pid /tmp/libguestfsJamIlZ/passt1.pid
...
> Don't run as root. Changing to nobody...
...
> PID file open: Permission denied
I think that might be due to an issue in the AppArmor policy from the
version shipped with Ubuntu 24.04 (that's a rather old version), but
I'm not entirely sure what it might be.
Aithal, could you have a look at /var/log/audit/audit.log (say,
"tail -f /var/log/audit/audit.log") while you're running this?
AppArmor access denials are logged there, as well as in the system log.
> libguestfs: trace: launch = -1 (error)
In libguestfs we already work around qemu changing its user when we
are running as root:
https://github.com/libguestfs/libguestfs/blob/0991b4dc2124a8d6c3d232663ea...
However I think because passt is creating the file, it cannot write
into the 0755 directory.
This is something we fixed:
https://passt.top/passt/commit/?id=c9b24134656925e53fea3cde0b33ab143dcd84af
the fix is not available in 0.0~git20240220.1e6f92b-1, and I'm generally
having little luck with requesting backports, e.g.:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2077158
but in any case that's not the issue Aithal is hitting here, because things
don't work as non-root anyway.
Honestly (just as with libvirt / qemu) unilaterally changing the
user
ID when running as root is not helping anyone nor adding any security.
I'd say that, minus that kind of issue which is obviously detrimental to
security, not being able to issue a number of system calls as root once
a guest connects is still decreasing the surface for possible attacks.
--
Stefano