[Csync2] csync2 and recent gnutls

[Lars Ellenberg]

On Tue, Sep 22, 2009 at 11:20:55AM +0200, Giampaolo Tomassoni wrote:
> > because commands run from ssh get their stdin/out/err connected to unix
> > sockets on the remote end, and csync2 tries to verify the peer address
> > via getpeername on stdin, assuming stdin to be an ipv4 tcp socket.
> 
> No, here you're not ;) It is not unix sockets, but pty devices.
> 
> One may attempt to use ssh -T ..., but I gets pipes on my Linux.

Ok, for csync2 or anything binary you'd of course need a transparent
channel, which you'd usually get, if stdin/stdout of ssh is not
connected to a terminal. Basically I assumed "-T -o BatchMode".

And, yes, OK, pipes, socketpairs, whatever ;)

> This is of course because ssh have to do all that auth and crypto work on
> data. Sorry, I didn't mind it.
> 
> > (which, btw, is also the reason why csync2 currently does not work with
> > ipv6 sockets)
> > 
> > Its not difficult to change that. One could simply patch that peername
> > check away, or add a "--pipe-mode" mode
> > (similar to imapd pre-authenticated mode, e.g.).
> > 
> > but I'd like to keep at least some plausibility check to avoid
> > accidental stray connections.
> > 
> > That is why I suggested to do the plausibility check for the via HELLO
> > presented peer name based on the SSH_CLIENT environment variable.
> 
> I now understand the problem, Lars.
> 
> However, the patch proposed in this thread is not going to solve it: it is
> only meant as a fix.

I'm clear on that, and I appreciate your work.

I just wanted someone else to do my job here,
and jumped on the opportunity ;)
Because I know I won't get to it for quite a time.

Someone else around to pick up this tunnel mode suggestion?

Oo.__

Never mind...

Cheers,

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.