Laine Stump <laine@xxxxxxxxx> schrieb am 9:17 Mittwoch, 15.Januar 2014:
This usually means that libvirt has been configured to run the qemu process as root, which introduces the possibility that a guest exploiting some theoretical security exploit in qemu could gain control of the host system. Normally libvirt installations will by default be configured to run the qemu-kvm process as user qemu, with all privilege bits cleared; either gentoo's default install of libvirt doesn't set things up this way, or you or someone else has modified /etc/libvirt/qemu.conf to change the "user" and "group" parameters to "root".
To fix this problem, edit /etc/libvirt/qemu.conf and either comment out those two parameters (if they aren't already commented out), or change them to set both user and group to "qemu" (assuming that gentoo follows the standard of adding a "qemu" user when installing libvirt), then restart the libvirt service and try starting the guest again.
Note, however, that this is a *warning*, not an error, so the guest should still be starting up and running. If not, then there should be some subsequent error message in the log (and/or look at the end of /var/log/libvirt/qemu/${vm}.log for error messages from qemu)
The problem is that the part that tells you something is pretty short: "Domain [...] is tainted: high-privileges"
Because when you run qemu-kvm from the commandline, it is being run as root. libvirt goes to great lengths to enable running the qemu-kvm process as "unprivileged" as possible, so that any potential security exploits in qemu-kvm will be as limited as possible in the damage they can do. Any operation that requires elevated privileges (e.g. creating a tap device to hook up the guest's networking, modifying the selinux labelling of various resources) is done by libvirt, which passed open file descriptors to the newly created resources to a qemu-kvm process that has been created running as an unprivileged user, with all privilege bits reset and pretty much all system resources limited by cgroups.
Well, in your system's libvirt configuration anyway.
The problem is not the "Domain is tainted" issue. I have set the privileges back to user libvirt (I had set it to root myself in libvirtd.conf) and the problem still exists.
2014-01-15 10:42:34.963+0000: 16162: info : libvirt version: 1.1.3.1
2014-01-15 10:42:34.963+0000: 16162: error : virDBusCallMethod:1173 : Launch helper exited with unknown return code 1
You can see now the "Domain is tainted" error (warning!) doesn't show anymore, but the domain still does not start. The only error message I get is the one above.
In /var/log/messages I still get:
Jan 15 10:42:34 dbus[15845]: [system] Activating service name='org.freedesktop.machine1' (using servicehelper)
Jan 15 10:42:34 dbus[15845]: [system] Activated service 'org.freedesktop.machine1' failed: Launch helper exited with unknown return code 1
I think the problem is in org.freedesktop.machine1. For some reason, that service cannot be activated, but I don't understand why.
Any help would be greatly appreciated.
On 01/15/2014 10:05 AM, Karoline Haus
wrote:
Good morning,
I'm using libvirtd on Gentoo.This is libvirt version: 1.1.3.1
I have trouble starting a VM using virsh start $vm. I do this as root, because as non-root user it did not work at all (especially it failed attaching to the networks). So, when I run the command (with sudo), I get the following error in libvirtd.log:
2014-01-15 07:51:00.423+0000: 16158: warning : qemuDomainObjTaint:1573 : Domain id=5 name='vader' uuid=f5b8c05b-9c7a-3211-49b9-2bd635f7e2aa is tainted: high-privileges
This usually means that libvirt has been configured to run the qemu process as root, which introduces the possibility that a guest exploiting some theoretical security exploit in qemu could gain control of the host system. Normally libvirt installations will by default be configured to run the qemu-kvm process as user qemu, with all privilege bits cleared; either gentoo's default install of libvirt doesn't set things up this way, or you or someone else has modified /etc/libvirt/qemu.conf to change the "user" and "group" parameters to "root".
To fix this problem, edit /etc/libvirt/qemu.conf and either comment out those two parameters (if they aren't already commented out), or change them to set both user and group to "qemu" (assuming that gentoo follows the standard of adding a "qemu" user when installing libvirt), then restart the libvirt service and try starting the guest again.
Note, however, that this is a *warning*, not an error, so the guest should still be starting up and running. If not, then there should be some subsequent error message in the log (and/or look at the end of /var/log/libvirt/qemu/${vm}.log for error messages from qemu)
2014-01-15 07:51:00.428+0000: 16158: error : virDBusCallMethod:1173 : Launch helper exited with unknown return code 1
At the same time I get an error in /var/log/messages which seems related:Jan 15 07:51:00 dbus[15845]: [system] Activating service name='org.freedesktop.machine1' (using servicehelper)
Jan 15 07:51:00 dbus[15845]: [system] Activated service 'org.freedesktop.machine1' failed: Launch helper exited with unknown return code 1
Anyone ever seen this issue? I have no idea where to look for errors because the message don't really tell me much.
The problem is that the part that tells you something is pretty short: "Domain [...] is tainted: high-privileges"
I have tried to execute the qemu-kvm command on the command line directly and that worked immediately.
Because when you run qemu-kvm from the commandline, it is being run as root. libvirt goes to great lengths to enable running the qemu-kvm process as "unprivileged" as possible, so that any potential security exploits in qemu-kvm will be as limited as possible in the damage they can do. Any operation that requires elevated privileges (e.g. creating a tap device to hook up the guest's networking, modifying the selinux labelling of various resources) is done by libvirt, which passed open file descriptors to the newly created resources to a qemu-kvm process that has been created running as an unprivileged user, with all privilege bits reset and pretty much all system resources limited by cgroups.
So the problem must be in libvirt.
Well, in your system's libvirt configuration anyway.
The problem is not the "Domain is tainted" issue. I have set the privileges back to user libvirt (I had set it to root myself in libvirtd.conf) and the problem still exists.
2014-01-15 10:42:34.963+0000: 16162: info : libvirt version: 1.1.3.1
2014-01-15 10:42:34.963+0000: 16162: error : virDBusCallMethod:1173 : Launch helper exited with unknown return code 1
You can see now the "Domain is tainted" error (warning!) doesn't show anymore, but the domain still does not start. The only error message I get is the one above.
In /var/log/messages I still get:
Jan 15 10:42:34 dbus[15845]: [system] Activating service name='org.freedesktop.machine1' (using servicehelper)
Jan 15 10:42:34 dbus[15845]: [system] Activated service 'org.freedesktop.machine1' failed: Launch helper exited with unknown return code 1
I think the problem is in org.freedesktop.machine1. For some reason, that service cannot be activated, but I don't understand why.
Any help would be greatly appreciated.
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
