[Spice-devel] [spice-gtk 0/5] Add support for looking up connection credentials in a file

[Daniel P. Berrange]

On Tue, Jun 04, 2013 at 11:16:26AM -0400, Marc-André Lureau wrote:
> 
> 
> ----- Mensaje original -----
> > On Tue, Jun 04, 2013 at 10:44:45AM -0400, Marc-André Lureau wrote:
> > > > This patch series adds support for something similar to what is described
> > > > in http://libvirt.org/auth.html: when a password is needed but it hasn't
> > > > been provided, we search for a file containing the auth info. It can be
> > > > specified through an environment variable, in the SPICE URI, then it's
> > > > looked up in XDG_CONFIG_DIR, and finally in /etc/libvirt/auth.conf.
> > > > There
> > > > are a few things that may deserve polishing in this scheme:
> > > > - it's quite libvirt centered with respects to the naming of the env var,
> > > >   of the default dir locations, ...
> > > > - the port number needs to be added to the auth-$SERVICE-$HOSTNAME scheme
> > > >   described on http://libvirt.org/auth.html as multiple VMs can run on
> > > >   the
> > > >   same host
> > > > - it does not go very well with libvirt automatic spice port allocation
> > > > as
> > > >   the credential file has to hardcode the port numbers, but the port
> > > >   number
> > > >   is not fixed when using automatic allocation
> > > > 
> > > > I still think this can be useful to people who are looking for a way to
> > > > pass spice password to the client without passing it on the command line
> > > > as
> > > > was suggested in https://bugzilla.redhat.com/show_bug.cgi?id=794644#c6
> > > 
> > > Spice-gtk is a library. Each Spice client may decide to provide
> > > credentials in its own way.
> > > 
> > > Why should spice-gtk bypass that? Since it's so libvirt-centered, why did
> > > you look for a solution in spice-gtk instead of virt-viewer?
> > 
> > In my opinion this fits best in spice-gtk so that we can document this in
> > one place, and have all applications using spice-gtk benefits from this
> > This is better than letting each application reinvent the wheel.
> 
> I don't think it is the right place to solve the problem.
> 
> virt-viewer has to auth against several servers, spice, vnc, libvirt, ovirt, (and could soon support rdp etc)
> 
> > What is libvirt-centered in these patches is just the env var/file names
> > (LIBVIRT_AUTH_FILE, $XDG_CONFIG_DIR/libvirt/auth.conf,
> > /etc/libvirt/auth.conf), this is trivial to change to something else if we
> > don't like it.
> 
> Then maybe we should get rid of that, and perhaps libvirt format doesn't fit well spice-gtk.
> 
> Since you can already provide the password via either URI argument or by API, there is no need for an additional way in spice-gtk.
> 
> Also, as you noted, it doesn't fit well with dynamic ports usually used with remote desktop protocols, we better keep password handling at application/virt-viewer level.

Yep, I really think this belongs at the virt-viewer level so that the
auth file records passwords against the VM names or UUIDs, not the TCP
port numbers or hosts. That way the same password can be setup to
work regardless of what host the VM is currently running on.

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