[Libguestfs] Can't access remote URI

[Daniel P. Berrange]

On Thu, Dec 20, 2012 at 09:53:17AM +0000, Richard W.M. Jones wrote:
> On Thu, Dec 20, 2012 at 05:30:03PM +0800, Wanlong Gao wrote:
> > On 12/20/2012 05:08 PM, Richard W.M. Jones wrote:
> > > On Thu, Dec 20, 2012 at 04:00:10PM +0800, Wanlong Gao wrote:
> > >> Hi Rich,
> > >>
> > >> We just found that the libguestfs can't access the remote URI.
> > >> When doing guestfs__add_drive_opts(), we always add files from
> > >> local system, it's related the -c|--connect option.
> > >>
> > >> As I know, we are using local kernel to lunch the min-guest,
> > >> and it's hard to attach remote disks to our local min-guest.
> > >>
> > >> Our test team found this problem by using following command,
> > >>
> > >> # virt-sysprep -c qemu+ssh://<host>/system -d domname
> > >>
> > >> Then, for example the path of remote disk is /work/rhel.img,
> > >> but we are about to access the /work/rhel.img locally.
> > >>
> > >> So, IMHO, if we are about to not support the remote URI, we
> > >> should give a error message first. But access local disks
> > >> instead of remote disks are definitely wrong here.
> > >>
> > >> Maybe we also need document this.
> > >>
> > >> Any thoughts?
> > > 
> > > John Eckersberg is working on implementing this for libguestfs 1.22.
> > > Most of the libvirt support has been done already, but there is some
> > > more libvirt and libguestfs work.
> > > 
> > > As for reporting an error, it's difficult because libvirt doesn't give
> > > a simple way to find out if a URI is "remote" or not (whatever
> > > "remote" means).  And even if libvirt did, it's not necessarily true
> > > that remote URIs wouldn't work, eg. if the user attached a LUN to both
> > > the remote and local machine.
> > 
> > So, at this time, we should report a useful message to user but not just
> > fail without any thing. Right?
> 
> I don't know how you can report a useful message, since it's not
> obvious if a libvirt URI is remote.  eg. How about the URI
> "qemu+ssh://foo/session" where the hostname of the local machine is
> "foo.example.com"?  Or the hostname is "bar.example.com" but the local
> DNS contains a PTR record "foo" -> "bar"?

In fact it is not merely a matter of whether the connection is remote
or not. You can have the same problem of being unable to access the
disk files if you're a unprivileged user connecting to the privileged
libvirtd.

Arguably you could just whitelist the URLs "qemu://session" (if
libguestfs is running getuid() != 0) and "qemu:///system" (if libguetsfs
is running getuid() == 0), and reject everything else until the tunnelling
support is ready.

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 :|