Re: Practical forwarding problem

[Frank Cusack <fcusack%fcusack.com@localhost>]

On September 22, 2005 8:47:55 PM -0400 der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> wrote:
> - User authentication succeeds.
> - Client opens a "session" channel (call it A).
> - Server confirms the open.
> - Client requests agent and X11 forwarding on A.
> - Server accepts forwardings.
> - Client sends an "exec" request on A.  The requested command is an X
>    terminal emulator.
> - Terminal emulator starts (opening an X connection) and backgrounds
>    itself (which looks like dying, to the server).
> - Server notices command death and sends EOF and CLOSE on A.
> - Client sends CLOSE on A, acking the server's CLOSE.
> - Server tears down forwardings for A, 'cause the channel's closed.
> - Something running under the terminal emulator does something which
>    wants agent access, or which wants a new X connection, but the
>    forwarding is now gone!
>
> Obviously, something here needs to change.  But what?  Everything
> leading up to the problem looks reasonable, but it sure adds up to
> "broken" in practice.  The most dubious point I see is the terminal
> emulator backgrounding itself - but that worked fine with the old ssh1
> implementation, and it doesn't seem totally unreasonable to expect it
> to work still.

This is a known problem, for openssh at least.  You shouldn't send
EOF and CLOSE (are these actual protocol messages?) on command termination,
you should only send it on EOF from the read fd connected to the command's
stdout.

The problem with that is you end up with "hung" sessions if you start
a background process that doesn't close it's stdout (e.g. attempting
to run a process as a daemon that really is meant to run in the foreground).
So a compromise is that you note process death but wait until your select()
or poll() loop indicates that there is no data ready.

For some reason, openssh on BSD and openssh on Linux act differently here,
due to kernel differences.  It's been so long that I don't remember the
details.

Now, if you implemented the compromise method, this wouldn't solve your
problem, because an idle xterm isn't going to have data ready.

But that's all a red herring, because really you should notice that the
forwarded session is still open and delay closing the session until
the forwarding has gone bye-bye.  At least, that's what openssh does.

Even if I'm off track here, I suggest sending a note to the openssh
list.  It sounds off topic for this list.

-frank