On Mon, Mar 11, 2013 at 01:21:48PM -0600, Eric Blake wrote: > 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. 'pt_chown' is a setuid helper program that GLibc can used to chown a PTY to the current user. It is however obsolete and no correctly configured Linux distro should require it anymore, since the dynamic devpts filesystem will provide a PTY that already has the correct ownership. As such it is correct that libvirt is blocking execution of pt_chown. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list