Bug 700523

Summary: clearing caps before running ssh breaks prevents ssh-askpass from launching from 'sudo virt-manager'
Product: Red Hat Enterprise Linux 6 Reporter: Travis Gummels <tgummels>
Component: libvirtAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: berrange, crobinso, dallan, dyuan, mzhan, qguo, rwu, syeghiay, veillard, whuang, yupzhang
Target Milestone: rcKeywords: TestOnly
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 02:27:26 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Travis Gummels 2011-04-28 11:21:14 EDT
Description of problem:

	Unable to open a connection to the libvirt management daemon.

Libvirt URI is: qemu+ssh://root@mandy.bencoyote.net/system

Verify that:
- The 'libvirtd' daemon has been started
Unable to open connection to hypervisor URI 'qemu+ssh://root@mandy.bencoyote.net/system':
cannot recv data: No protocol specified

(ssh-askpass:22562): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.

No protocol specified

(ssh-askpass:22563): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.

No protocol specified

(ssh-askpass:22564): Gtk-WARNING **: cannot open display: :0.0
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

: Connection reset by peer
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 992, in _try_open
None], flags)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 111, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: cannot recv data: No protocol specified

(ssh-askpass:22562): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.

No protocol specified

(ssh-askpass:22563): Gtk-WARNING **: cannot open display: :0.0
Permission denied, please try again.

No protocol specified

(ssh-askpass:22564): Gtk-WARNING **: cannot open display: :0.0
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

: Connection reset by peer

Maybe you need to install ssh-askpass in order to authenticate.

[ben@snog tmp]$ rpm -q virt-manager
virt-manager-0.8.4-8.el6.noarch

The problem seems to be one of access or privileges.

Sifting through the log you can see:
22562 execve("/usr/libexec/openssh/ssh-askpass", ["/usr/libexec/openssh/ssh-askpass", "root@mandy.bencoyote.net's passw"..
.], [/* 23 vars */]) = 0
...
22562 connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
...
22562 access("/var/run/gdm/auth-for-ben-JwgDaN/database", R_OK) = -1 EACCES (Permission denied)

So what is happening is we exec a process ssh-askpass it tries to connect to the X server but to be able to connect to the screen it needs to get the authority file which ends up being denied for some reason even though the process was run as root.

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

virt-manager-0.8.6-3.el6.noarch

How reproducible:

$ sudo virt-manager

you can't connect to a remote machines via ssh. The problem seems to have something to do with connecting back to the xserver.

however if you do:

$ virt-manager

you can connect.
  
Actual results:

Connection denied.

Expected results:

Connection succeeds.
Additional info:
Comment 1 Cole Robinson 2011-07-22 11:28:09 EDT
I can reproduce. I managed to get it working with a libvirt patch:

diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
index d4c0bdd..ad1c02e 100644
--- a/src/rpc/virnetsocket.c
+++ b/src/rpc/virnetsocket.c
@@ -606,7 +606,8 @@ int virNetSocketNewConnectSSH(const char *nodename,
     virCommandAddEnvPass(cmd, "SSH_AUTH_SOCK");
     virCommandAddEnvPass(cmd, "SSH_ASKPASS");
     virCommandAddEnvPass(cmd, "DISPLAY");
-    virCommandClearCaps(cmd);
+    virCommandAddEnvPass(cmd, "XAUTHORITY");
+    //virCommandClearCaps(cmd);
 
     if (service)
         virCommandAddArgList(cmd, "-p", service, NULL);

Passing through XAUTHORITY seems okay, but I don't think dropping ClearCaps wholesale is a good idea. Reassigning to libvirt to see if anyone has more thoughts.
Comment 2 Dave Allan 2011-07-22 16:19:01 EDT
Cole, I'm not sure anybody on the libvirt team is going to have more insight into this than you do.  Would you mind submitting that patch to libvir-list for discussion there?
Comment 3 Daniel Berrange 2011-07-25 10:04:30 EDT
The SSH client should not need to elevate its privileges on the client side, so blocking any setuid() usage is a desirable feature IMHO.
Comment 5 Cole Robinson 2011-08-25 10:19:18 EDT
Upstream discussion:

http://www.redhat.com/archives/libvir-list/2011-July/msg01694.html

Not sure of any way to solve this issue without preserving capabilities, so back to the drawing board I guess.
Comment 8 Huang Wenlong 2011-11-23 04:27:28 EST
Hi,
I can reproduce this bug with libvirt-0.9.3-2.el6.x86_64 


steps: 
1) use a no-root  user  
$cat test.py 
#!/usr/bin/python
import os
import sys
import libvirt

def drop_tty():
    if os.fork() != 0:
        os._exit(0)
    os.setsid()

host = sys.argv[1]

# Need to drop controlling tty otherwise SSH won't call askpass
drop_tty()
libvirt.open("qemu+ssh://root@%s/system" %host)

2) $ sudo python  test.py $host_ip 

[whuang@intel-i7-12-4 tmp]$ libvir: RPC error : Cannot recv data: Permission denied, please try again.
Permission denied, please try again.
: Connection reset by peerey,gssapi-keyex,gssapi-with-mic,password).
Traceback (most recent call last):
  File "test.py", line 15, in <module>
    libvirt.open("qemu+ssh://root@%s/system" %host)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 236, in open
    if ret is None:raise libvirtError('virConnectOpen() failed')
libvirt.libvirtError: Cannot recv data: Permission denied, please try again.
Permission denied, please try again.
: Connection reset by peerey,gssapi-keyex,gssapi-with-mic,password).


BTW,
But maybe this bug is fixed in the  libvirt-0.9.4-23.el6.x86_64 or it can not be reproduced ,it will pop up askpass window and can connect successfully in this version with the same steps
Comment 9 Dave Allan 2012-01-04 14:51:42 EST
(In reply to comment #8)
> But maybe this bug is fixed in the  libvirt-0.9.4-23.el6.x86_64 or it can not
> be reproduced ,it will pop up askpass window and can connect successfully in
> this version with the same steps

Based on this comment, I'm marking this BZ as TestOnly and moving to MODIFIED for verification.
Comment 10 yuping zhang 2012-01-06 04:00:09 EST
Reproduced this issue with libvirt-0.9.3-2.el6.x86_64.

Verified it with:
libvirt-client-0.9.9-0rc1.el6.x86_64
libvirt-python-0.9.9-0rc1.el6.x86_64
libvirt-0.9.9-0rc1.el6.x86_64

Steps:
1.Use a non-root user.
2.[yuping@dhcp-93-226 virsh]$ sudo virt-manager 
[sudo] password for yuping: 
3.Add a connection to remote host with qemu+ssh://<host-ip>/system
4.Connect to the remote host successfully. No errors pop up.

So change the status to "VERIFIED"
Comment 13 errata-xmlrpc 2012-06-20 02:27:26 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0748.html