Bug 1045033

Summary: LIBVIRT_DEFAULT_URI=qemu:///system breaks libguestfs
Product: [Fedora] Fedora Reporter: Richard W.M. Jones <rjones>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: berrange, clalancette, crobinso, itamar, jforbes, jyang, laine, libvirt-maint, mbooth, ptoscano, rjones, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libguestfs-1.24.5-1.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1045069 (view as bug list) Environment:
Last Closed: 2014-01-30 03:38:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1045069    
Bug Blocks: 910269    

Description Richard W.M. Jones 2013-12-19 13:43:34 UTC
Description of problem:

Stefan had this environment variable set:
LIBVIRT_DEFAULT_URI=qemu:///system

This breaks libguestfs, eg:

$ libguestfs-test-tool

[...]

libguestfs: error: could not create appliance through libvirt.
Try using the direct backend to run qemu directly without libvirt,
by setting the LIBGUESTFS_BACKEND=direct environment variable.: internal error: process exited while connecting to monitor: qemu-system-x86_64: -chardev socket,id=charserial0,path=/tmp/libguestfsB40jqN/console.sock: Failed to connect to socket: Permission denied
qemu-system-x86_64: -chardev socket,id=charserial0,path=/tmp/libguestfsB40jqN/console.sock: chardev: opening backend "socket" failed
 [code=1 domain=10]

Version-Release number of selected component (if applicable):

libvirt-daemon-1.1.3-2.fc21.x86_64

How reproducible:

100%

Steps to Reproduce:
1. As above.

Comment 1 Daniel Berrangé 2013-12-19 13:51:59 UTC
Why is libguestfs relying on automatic probing of libvirt URIs ? This is only suitable for applications which are able to run against any libvirt virtualization driver - there's no guarantee it'll even be QEMU. Libguestfs should explicitly request qemu:///session if non-root, or qemu:///system if running as root.

Comment 2 Richard W.M. Jones 2013-12-19 14:09:21 UTC
(In reply to Daniel Berrange from comment #1)
> Why is libguestfs relying on automatic probing of libvirt URIs ? This is
> only suitable for applications which are able to run against any libvirt
> virtualization driver - there's no guarantee it'll even be QEMU. Libguestfs
> should explicitly request qemu:///session if non-root, or qemu:///system if
> running as root.

Isn't qemu:///system always wrong?  It has caused us a lot of
trouble in the past, eg: bug 913774, bug 984409.  Why can't
we always specify qemu:///session?

Also I'd say the documentation here:
http://libvirt.org/drvqemu.html#uris
doesn't reflect the reality.  (But it would be nice if root
had session guests).

Comment 3 Daniel Berrangé 2013-12-19 14:11:24 UTC
If libguestfs is running as root then there is no qemu:///session instance you can use - qemu:///system is your only choice.

Comment 4 Daniel Berrangé 2013-12-19 14:37:22 UTC
NB, I'm not entirely against the idea of introducing a way to use 'qemu://session' when running as root.  The distinction of system vs session was motivated by the way dbus separates its system and session bus. When run as root, dbus still allows creation of a session bus for root.

We've got a long historical practice where libvirtd uses getuid==0 to determine whether it runs in system vs session mode, so we'd need to some flag to force it to use session mode. We then also probably need to audit every single piece of code which looks as 'bool privileged' to see that it still makes sense when running in session mode as root.

Comment 5 Richard W.M. Jones 2013-12-19 14:47:43 UTC
Patch posted for this bug here:
https://www.redhat.com/archives/libguestfs/2013-December/msg00085.html

Comment 6 Fedora Update System 2014-01-21 08:44:33 UTC
libguestfs-1.24.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libguestfs-1.24.5-1.fc20

Comment 7 Fedora Update System 2014-01-22 03:10:47 UTC
Package libguestfs-1.24.5-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libguestfs-1.24.5-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-1262/libguestfs-1.24.5-1.fc20
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2014-01-30 03:38:48 UTC
libguestfs-1.24.5-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.