Re: [libvirt] using virSetUIDGID() with unprivileged qemu defeats setuid helper
On 03/10/2013 10:25 PM, Csaba Henk wrote:
Hi,
I recently experienced that my qemu guest (which I'm using with
unprivileged user) fails to start with:
error: internal error process exited while connecting to monitor: chardev: opening
backend "pty" failed
This happens upon trying to facilitate the
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
stanzas, for which qemu wants to grab a pty through openpty(3).
openpty needs to have the assigned pty to be chown'd to the qemu
user, which is attempted via running the setuid helper program
pt_chown. However, chown(2) fails with EPERM.
Thanks for the analysis.
The culprit seems to be the commits
v1.0.3-rc1~113: util: virSetUIDGIDWithCaps - change uid while keeping caps
v1.0.3-rc1~112: util: maintain caps when running command with uid != 0
which change how capabilities are manipulated before program execution.
Just immediately before the execve(2) call, the qemu process used to have
the following capabilities:
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
since said commits, it looks like:
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffe000000000
We are intentionally dropping capability bits; however, your report
means we need to think twice about dropping CAP_CHOWN when there is a
pty in play.
as far as my capability-noob eyes can see, the bounding set lacks CAP_CHOWN
and thus pt_chown won't attain CAP_CHOWN despite running on uid 0, and the
EPERM is triggered.
How could we fix it? Qemu invocation should be customized or virExec() adjusted?
Or is there some configuration workaround?
Ideally, we would fix libvirt to open the pty and then hand the fd to
qemu via SCM_RIGHTS, rather than letting qemu have to keep CAP_CHOWN.
That way, qemu will never need to spawn the helper pt_chown app, and the
lack of the capability would not be an issue. But if that doesn't work
out, then the fact that we can hot-plug a console means that we cannot
know, at qemu start time, whether a later operation would hotplug a pty,
so we may be forced to leave CAP_CHWON in the bounding set of all qemu
processes.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)