virt-manager assumes root user for qemu+ssh hosts

Bug #294965 reported by Bryan McLellan on 2008-11-07
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Won't Fix
virt-manager (Ubuntu)

Bug Description

Binary package hint: virt-manager

This is a packaging regression.

virt-manager=0.5.3-0ubuntu10 contained a patch fix_heuristic.patch, which removed the hardcoded root username from virtManager/ virt-manager=0.5.4-2ubuntu1 lacks this patch.

Thus in virt-manager=0.5.4-2ubuntu1 all newly created qemu+ssh sessions try to connect using the root user. This works if you know the root password, but is not preferable. Since access to libvirt can be controlled by permissions on /var/run/libvirt/libvirt-sock[-ro], it is poor design to use the root user to connect to libvirt, and is neither the UbuntuWay.

Adding the URI as 'username@host' creates a uri like 'qemu+ssh://root@username@host/system', which doesn't work at all.

The work around is to use gconf-editor to modify the uris key in apps -> virt-manager -> connections, adding uri's by hand.

Description of problem:

Virt-manager forces the creation of qemu+ssh and xen+ssh URI's to include the root user.

Steps to Reproduce:
1. File, Open Connection
2. Choose Remote tunnel over SSH
3. Enter a hostname

Actual results:

The URI generated is 'qemu+ssh://root@hostname/system'

Expected results:

The URI generated should be 'qemu+ssh://hostname/system'

Additional info:

libvirt does not require root access and should frown upon using the root account to access libvirt if anything. A username should not be hardcoded, or at the least should detect if a username is provided in the entry field and use that instead.

See src/virtManager/

Changed in virt-manager:
status: Unknown → Confirmed
Soren Hansen (soren) wrote :

You're absolutely right. I'll prepare an SRU ASAP. Thanks!

Changed in virt-manager:
assignee: nobody → soren
status: New → In Progress
Robstarusa (rob-naseca) wrote :

I have this same issue. I couldn't believe the error I saw when I saw it. I have created a user that (from local machine) can access qemu:///system, but virt-manager is broken exactly as described above.

Thanks for working on this Soren!

Thanks for the report. Just committed a fix for this, the user can now specify the username via user@hostname syntax when opening a new connection:

I think this is the safest fix, rather than change existing behavior when no username is specified.

Closing as UPSTREAM.

Changed in virt-manager:
status: Confirmed → Invalid
Bryan McLellan (btm) wrote :

This has been patched upstream [1] but there hasn't been a release since 0.6.0 on 2008-09-10. Accordingly, jaunty at the moment has virt-manager=0.6.0-6ubuntu1, which does not have this patched.

So this bug currently exists in the version of virt-manager that will ship with 9.04.


Changed in virt-manager:
status: Invalid → Fix Released
Jamie Strandboge (jdstrand) wrote :

I'm still seeing this on karmic virt-manager 0.7.0-3ubuntu1.

On Fri, Aug 7, 2009 at 3:52 AM, Jamie Strandboge<email address hidden> wrote:
> I'm still seeing this on karmic virt-manager 0.7.0-3ubuntu1.

in jaunty (virt-manager=0.6.1-1ubuntu4) you can specify "user@host"
for qemu+ssh sessions, but if you don't specify a username it defaults
to using root.

Is this not the case in karmic?

Soren Hansen (soren) wrote :

Yes, in Karmic you can specify "username@" before the hostname. However, I agree that "root" is a horrible default on Ubuntu, since we don't enable root logins by default.

Soren Hansen (soren) on 2009-09-08
Changed in virt-manager (Ubuntu):
importance: Undecided → Wishlist
Nicolas Diogo (nicolasdiogo) wrote :


just checking if the release has been committed and propagated in Hardy (host) and 9.10 (remote clients).

i just tried and it is quite a shock to be asked for my root password..

thanks a lot

Soren Hansen (soren) on 2009-10-08
Changed in virt-manager (Ubuntu):
assignee: Soren Hansen (soren) → nobody
status: In Progress → Triaged
David Ayers (ayers) wrote :

This is still the case for both:
Lucid 10.04 LTS
Maverick 10.10

Marc Deslauriers (mdeslaur) wrote :

This is fixed now in virt-manager 0.8.6 in natty.

Changed in virt-manager (Ubuntu):
status: Triaged → Fix Released
Changed in virt-manager:
importance: Unknown → Medium
status: Fix Released → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.