[libvirt] using virSetUIDGID() with unprivileged qemu defeats setuid helper

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130311/0f4e7c85/attachment-0001.sig>