Re: Practical forwarding problem

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

Replying to three messages at once, here.

>> [issue with forwardings being torn down before they're wanted]

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

> The server could notice that their are still child processes alive
> and send EOF but not CLOSE.

This is approximately impossible on at least some of my target OSes; if
A forks B and B forks C and B then dies, A has no way (well, no easy or
clean way) to find out that B forked C at all, much less that C still
exists.

> Not great, since it might be that the user intended these child
> processes to run in the background after logout...

There's that, too.

>> - Client sends CLOSE on A, acking the server's CLOSE.
>> - Server tears down forwardings for A, 'cause the channel's closed.
> The Server could 'associate' the forwarding with the connection
> instead of the channel... and not tear it down until the connection
> dies.

That breaks connection sharing.  What I considered is allowing the
active forwardings to keep the session channel alive when it would
otherwise be closed, but then there's the problem of telling when you
*do* want to shut it down.  (But see David Terrell's idea, below.)

> In this model, a second agent-forwarding request on a second session
> channel would not result in a second unix domain socket being
> created, but would simply result in th environment variable being set
> to point to the 'connection' forwarding.

That sounds good, except it breaks if the two agent forwarding requests
are trying to provide forwarded access to different agent
instantiations.  (Mutatis mutandis for X, of course.)

> In the end, I think it comes down to the fact that agent and x11
> forwarding really should be connection level operations...

Perhaps, but that point of view is fundamentally incompatible with
connection sharing (which is *very* desirable for someone who, like me,
is on old half-lung hardware that can quite literally take minutes to
do kex and authentication).  Or at least with connection-sharing for
decoupled sessions.

[David Terrell <dbt%meat.net@localhost>]

> Option 1) Keep the terminal open until you're done

This is what I've started doing.  I didn't like it at all at first, and
still don't really like it that much, but I've made a mental shift to
seeing the old way's working as an accident of that implementation
rather than a "how it's supposed to work", which makes it easier to
accept the difference when I switch.

> Option 2) Keep open all forwardings as long as there's
> 	a) a forwarded session
> 	b) a forwarded x session

That is a sensible suggestion.  I may try it someday.

The real problem here is that I want to hand a capability to a process,
to pass on to descendants, and I want to know as soon as nobody who has
it is still alive any longer.  The only thing I can think of which fits
this in stock Unix is a file descriptor.  I could do that for agent
access, but I don't think I could for X access, not without hacking up
Xlib as well - and even for agent access, it's hard to get the
descriptor past things like shells which (not unreasonably) go to some
lengths to close all file descriptors they don't understand.

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

> This is a known problem, for openssh at least.  You shouldn't send
> EOF and CLOSE (are these actual protocol messages?)

Yes - SSH_MSG_CHANNEL_EOF and SSH_MSG_CHANNEL_CLOSE, to give them their
full names.

> on command termination, you should only send it on EOF from the read
> fd connected to the command's stdout.

Perhaps, but...

> The problem with that is you end up with "hung" sessions if you start
> a background process that doesn't close [its] stdout [...]

...I've run into that kind of wedgitude in the past, so I'm reluctant
to do that in that form.

> So a compromise is that you note process death but wait until your
> select() or poll() loop indicates that there is no data ready.

That helps with races between process exit and output flushing, but not
with a situation like this one, where the process quite likely will
_never_ produce any output.

> 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.

Not according to connect-25:

   X11 connection forwarding should stop when the session channel is
   closed.  However, already opened forwardings should not be
   automatically closed when the session channel is closed.

To me, that quite clearly says that I *should* shut down the forwarding
when the session channel closes.

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

Really?  OpenSSH is not involved in any way in the cases in which I ran
into this.

Anyway, thanks for all the thoughts.  I'll let them (and any more that
may show up) rattle around for a day or two and see if I can't settle
on something.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B