[libvirt] SSH URIs invoking askpass + sudo don't play well together

[Daniel P. Berrange]

On Fri, Jul 22, 2011 at 04:38:20PM -0400, Cole Robinson wrote:
> $ cat test.py
> 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)
> 
> $ python test.py localhost
> <askpass pops up>
> 
> $ sudo python test.py localhost
> libvir: RPC error : Cannot recv data: No protocol specified
> 
> (ssh-askpass:25684): Gtk-WARNING **: cannot open display: :0.0
> : Connection reset by peered.
> Traceback (most recent call last):
>   File "test.py", line 14, in <module>
>     libvirt.open("qemu+ssh://root@%s/system" % host)
>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 236, in open
>     if ret is None:raise libvirtError('virConnectOpen() failed')
> libvirt.libvirtError: Cannot recv data: No protocol specified
> 
> (ssh-askpass:25684): Gtk-WARNING **: cannot open display: :0.0
> : Connection reset by peered.
> 
> 
> virt-manager does drop_tty by default so that users will get askpass if
> applicable. however as shown above, doing sudo virt-manager prevents this from
> working. The following libvirt patch makes everything work:
> 
> 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);
> 
> 
> However I assume that's too heavy handed. Anyone have thoughts?

Yeah, the ssh client really shouldn't be needing to change privileges
todo anything, so blocking capabilities is a desirable feature IMHO.

Invoking X applications using sudo has always been nothing but trouble
for all sorts of reasons. The desktop integration services really hate
it.

Passing a few more env vars like XAUTHORITY does make reasonable sense
though in general.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|