ControlPersist and multiple X11 forwarding.
dwmw2 at infradead.org
Tue Sep 6 21:57:10 EST 2005
On Sun, 2005-09-04 at 17:46 +0100, David Woodhouse wrote:
> The second causes control clients to pass X11 display, auth proto and
> auth data over the control socket so that appropriate X11 forwarding can
> happen for each, instead of using $DISPLAY and $XAUTHORITY of the master
> even for all the clients.
I hadn't realised that xfree(NULL) was forbidden. Updated patch #2.
Note that this also fixes a memory leak in client_process_control() in
the case where sending an empty buffer back to the client fails.
I've collected the current set of patches at
I've dealt with the most important features I think are lacking in 4.2,
but there's a few more minor things to fix yet.
- I'd like a better answer than the 'slack-fds' patch, and especially
the hard-coded '+2' in it. Perhaps we should keep count of the
number of 'pending' file descriptors which may be opened by the
channel_pre handlers at any time?
- The master should permit X11 forwarding for clients, even if X11
forwarding wasn't enabled on the original connection. While we're at
it, we should pass the 'forward_x11_trusted' option over the control
- Should investigate multiple agent forwarding. That's somewhat harder
than multiple X11 forwarding, and may not be possible at all. But the
lack of multiple agent forwarding is less of a problem than the lack
of multiple X11 forwarding; at least for me.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4304 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050906/dbefd8ac/attachment.bin
More information about the openssh-unix-dev