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: |
Description
Travis Gummels
2011-04-28 15:21:14 UTC
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 |