Three patches attached. One implements a 'ControlPersist' option, which when used with 'ControlMaster auto' or 'ControlMaster 'yes' make makes the master background itself and stick around after its own primary session is completed. 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. The third dispenses with the 'Already forwarding for a different $DISPLAY' error, to make the second patch actually useful. We delay opening the connection to the X server until after we've seen an authentication attempt, and since each set of fake authentication data is unique, we can use that to work out which server to connect to. The third patch isn't quite ready yet. Is the way I did the use count on the X11 forwarding structure the best way to do it? And why does the X11 connection stall after authentication, until after some other traffic occurs between client and server? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.2p1-controlpersist.patch Type: text/x-patch Size: 2148 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050904/cbb54e4c/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.2p1-controldisplay.patch Type: text/x-patch Size: 4241 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050904/cbb54e4c/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.2p1-multidisplay.patch Type: text/x-patch Size: 12412 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050904/cbb54e4c/attachment-0002.bin
On Sun, 2005-09-04 at 17:46 +0100, David Woodhouse wrote:> And why does the X11 connection stall after authentication, until > after some other traffic occurs between client and server?To answer my own question... it's because we allocated a new file descriptor and increased channel_fd_max, but we did so only _after_ channel_prepare_select() had already set *maxfdp and made sure that the fd_sets were large enough to cope. So we don't get to select on the new one until the _next_ time round the loop. Not only that, but when we do FD_SET the new file descriptor in an existing fd_set, we could be scribbling over random memory because the fd_set isn't actually large enough. A quick but dirty workaround is just to have channel_prepare_select() allow for one or two more file descriptors than we actually need. If we can get _many_ simultaneous X11 authentication packets, though, all on different connections, then that won't be sufficient. Better suggestions...? --- openssh-4.2p1/channels.c~ 2005-09-05 09:05:21.000000000 +0100 +++ openssh-4.2p1/channels.c 2005-09-05 09:05:56.000000000 +0100 @@ -1779,7 +1779,8 @@ channel_prepare_select(fd_set **readsetp { u_int n, sz; - n = MAX(*maxfdp, channel_max_fd); + /* Allow for two more fds to be allocated */ + n = MAX(*maxfdp, channel_max_fd + 2); sz = howmany(n+1, NFDBITS) * sizeof(fd_mask); /* perhaps check sz < nalloc/2 and shrink? */ -- dwmw2
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 http://david.woodhou.se/openssh-control.html 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 socket too. - 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. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.2p1-controldisplay.patch Type: text/x-patch Size: 4304 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050906/dbefd8ac/attachment.bin