[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] problems with remote authentication with policykit

Daniel P. Berrange wrote:
> On Thu, Jun 18, 2009 at 12:20:40PM -0400, Jim Paris wrote:
> > I'm using Debian.  I've already had to switch from the
> > "netcat-traditional" package to the "netcat-openbsd" package.
> > Debian does already include that patch, but what a mess...
> I know the reason why it gets stuck on the server end too - after an
> auth failure, the server won't kick off the client. The connection
> just remains in an unauthenticated state. This allows the client to
> (in theory) retry the authentication step, and gives us a little more
> flexibility for any future protocol changes we might need to make.

Makes sense -- it would be nice for the client to be able to retry
with read-only authentication when read-write fails, without having to
reopen the SSH connection.  Or is that not possible, since it would
require opening a different socket?

> I think the best way to solve the problem of 'nc' potentially not
> quitting promptly, is to simply have the remote client kill() the
> SSH client pid, rather than simply closing the socket & doing
> waitpid() on the SSH client. This would ensure the waitpid promptly
> cleans up.

Yeah, that should fix the hang.

> > Since already know libvirtd is installed on the remote host,
> > would it make sense to just add a new set of options:
> >       libvirtd --socket-connect
> >       libvirtd --socket-connect-ro
> > that do the same thing as "nc -U" on the appropriate socket?
> > Then we know it would work everywhere, and have the added 
> > benefit that the client wouldn't need to know the location of the
> > socket.
> If we'd thought of this originally, I would certainly have done it
> this way, but if we did this now, it would break compatability. ie
> new libvirt clients would be trying to run a binary that does not
> exist with old server deployments.

It could still be done in a backwards-compatible way.  Something like:

  ssh server "libvirtd --socket-connect || nc -U /socket"

Or, if you really wanted to be nice to us Debian folks,

  ssh server "libvirtd --socket-connect || nc.openbsd -U /socket || nc -U /socket"

(while the Debian libvirt package does depend on netcat-openbsd,
there's nothing that forces the local "nc" symlink to point to the
openbsd version over the traditional version, if both are installed).

It's definitely messy, but it would really be nice to remove the need
for the client to know which netcat to use, or where sockets are
located, etc.

Hmm, as I think about it more, I guess netcat is also used for VNC
connections?  I wonder if that could be implemented as a dynamic port
forward on the existing SSH connection, which would also eliminate
the need for a second connection (and having to enter the password a
second time)...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]