FEATURE: -f -f - fork after successful open of fwd port/display/agent

[Nicolas Williams]

On Mon, Feb 04, 2002 at 10:59:48AM -0500, Dan Astoorian wrote:
> On Mon, 04 Feb 2002 09:52:25 EST, Nicolas Williams writes:
> > 
> > Do you have any wrappers that add -f? I think I can code wrappers to be
> > smart enough about this, so I'm not concerned.
> 
> You're approaching the question from the wrong direction.  Can *you*
> guarantee that nobody else has wrappers that add -f?  If someone has, do
> you think this feature justifies breaking their existing deployment when
> they upgrade OpenSSH, when this could trivially have been avoided?

See below.

> I'm not arguing because I have wrappers that your feature will break;
> I'm arguing because I don't want OpenSSH's design to grow unnecessary
> tumours.

How is this a tumor?

> And for what it's worth, yes, I do have a wrapper which adds -f: my
> users use it to launch X applications.  I could also add code to my
> wrapper to filter out multiple -f's.  I shouldn't have to.

Precisely. You wouldn't mind an accidental -f -f because the ssh client
will still exit pretty soon after starting.

"ssh -f -f" will almost never change the behaviour vis-a-vis "-f" in a way
that would "break" anything when it's used to start X11 apps.

> > > but the idea of '-f -f' having a *qualitatively* different meaning than
> > > '-f' is a little unsettling.  You're not using "-f -f" to mean "-f, only
> > > more so"; it appears as if you just didn't want to use up another letter
> > > for a option with nearly identical semantics.
> > 
> > No, I'm making "-f -f" mean "like -f, but a bit later".
> 
> And that's a substantial, qualitative difference.  You're changing the
> interpretation of the return code, and in the case where the command
> doesn't happen to use forwarding features, you're preventing the
> backgrounding from taking place at all.  Consider the difference in
> behaviour for:

Yes, this is the one time "-f -f" is a significant change vs. "-f". But,
note that the "-f" option is intended for use with X11 app launching
(see the ssh(1) man page).

> > > Think harder :-)
> > 
> > Sure. Have you any suggestions?
> 
> No, but then, I don't approve of the feature.

See below.

> > I agree on principle. But there are exceptions to rules of thumb and I
> > think this is one of them. Have you understood the feature?
> 
> I haven't read the patch, but yes, I understand what you're trying to do
> with this feature, and I still think the benefits of this feature are
> outweighed by its poor fit into the existing design (which could make
> the feature difficult to maintain in the future).

Would you mind it if the option were "-ff"?

> You can't guarantee that the X11 display has been opened successfully
> even if the forwarding has been established.  The X11 display could
> refuse the connection at the X protocol level, or the X11 app could
> abort between opening the X11 server and mapping its first window, for
> any of a number of reasons.

Nor can I guarantee that the remote app won't go into an infinite loop
and never attempt to open the display.

Yet I still find this feature useful because it allows me to catch most
common errors.

> In any case, it's not ssh's job to make sure the application operates as
> intended.

But ssh does bother to try to give me a remote command's exit code.

> > People use "ssh -f ..." as an approximation of "ssh -f -f ..." for
> > launching X apps. Visual feedback tells them whether or not something
> > went wrong.
> 
> Or stderr tells them.

Too late with -f.

> > But suppose you're writing a GUI app so users can start X apps with a
> > click of a mouse. How do you check for errors in starting the remote
> > apps? [...]
> 
> Watch the stdout/stderr of the ssh process, and don't use -f.  If you

That means knowing what to look for (as opposed to looking for a
non-zero exit number, at which point whatever was written to stderr can
be presented to the user).

> have an application for which you have a particular need to verify that
> it started up correctly, make the application output a positive
> acknowledgement to stdout or stderr, and have the launcher watch for it.

That means changing the apps.

> The original purpose of -f was to let ssh stay in the foreground long
> enough to prompt for passphrases; if you're doing it from a window
> manager, there's usually no downside to just putting the whole process
> in the background.

Sure, the GUI remote app launcher can deal with lots of ssh children.
But how can it know that the apps actually got to open the display?

Also, I'm still looking for comments on the forkoff() thing. It makes a
big difference on Cygwin, where starting OpenSSH from a native Windows
app causes a new command window to open - the forkoff() function I added
has an option to detach from the tty (and close the session channel),
which causes the window to go away as soon as OpenSSH -f orksoff.

> -- 
> Dan Astoorian               People shouldn't think that it's better to have
> Sysadmin, CSLab             loved and lost than never loved at all.  It's
> djast at cs.toronto.edu        not, it's better to have loved and won.  All
> www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican



Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.