[libvirt] SSH URIs invoking askpass + sudo don't play well together
Daniel P. Berrange
berrange at redhat.com
Mon Jul 25 14:32:47 UTC 2011
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 :|
More information about the libvir-list
mailing list