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: | libvirt | Assignee: | Cole Robinson <crobinso> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | berrange, crobinso, dallan, dyuan, mzhan, qguo, rwu, syeghiay, veillard, whuang, yupzhang |
| Target Milestone: | rc | Keywords: | 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 06:27:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.
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? The SSH client should not need to elevate its privileges on the client side, so blocking any setuid() usage is a desirable feature IMHO. 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. 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
(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. 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" 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 |
Description of problem: Unable to open a connection to the libvirt management daemon. Libvirt URI is: qemu+ssh://root.net/system Verify that: - The 'libvirtd' daemon has been started Unable to open connection to hypervisor URI 'qemu+ssh://root.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.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: