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.