Tony, Kurt, All,

On Tuesday 06 September 2005 22:01, Kurt V. Hindenburg wrote:
> On Sunday 28 August 2005 18:12, Tony Gravagno wrote:

> | anyone who wants it.  It can be added to the standard code base or it can
> | fork to a separate open source repository so that existing Konsole users
> | don't feel vulnerable to trojans from untrusted servers.  But for those
> | who want the features bad enough, I think they're going to have to
> | commission the development effort and subsequent support, or they simply
> | won't get what they want.

Tony, it actually did not become clear to me, what they really want. But if 
the issue is:

- on host A: open a telnet connection to host B.
- on host A: enter a command to be started on B.
- on host B: the command wants to do something on host A during its execution.

Then, the normal way to do so is to delegated the command from host B onto 
host A using ssh. If a command such executed produces output or demands for 
keystrokes, all is already perfectly arranged.

I.e.: Call back using _another_ line. Do not (ab)use the line of original 
telnet session. 

It is because this procedure requires an authorization, in which host B makes 
clear to host A that it is entitled to execute commands on host A.

The point is, that this right cannot assumed to be granted by logging into 
host B and executing a command there.

(Use ssh-copy-id from host A to host B to grant that right if you do not like 
to acknowledge it per instance.)

(If the command shall additionally be executed immediately on login to host B, 
one could arrange such using .bash_login or another configuration file for 
the login shell on host B, for instance.)

None of these solutions do need any modification of the konsole. It appears 
they have more a kind of a remote scripting problem, stumbling over security 
barriers, as they should.


> | While you indicate that driving a localhost from a remote host is not
> | already in Konsole, it seems to me that it would be pretty easy to make
> | this happen.  I've provided a link to my notes on this here:
> | http://tinyurl.com/7ffrq  You can read up from that thread to see how
> | this subject unfolded.

Yes, it is easy to do. It was never included into the konsole for security 
reasons. It's absence is a feature, not an omission.

In general, it is an extremely bad idea to a allow a terminal to change 
anything on the localhost but its screen.  Not always obvious, even the most 
innocent such "features" are only security holes by their very nature.

For instance. From the dos times, i remember that the dos ansi implementation 
allowed to set the key sequences via escape codes, a "feature" intended to 
allow to adapt the function keys to the needs of the (remote) application. 
This means, it was remotely possible this way, to set the return key to emit 
something malicious like "del *.*\n" immediately before closing the remote 
session.

Likely, zmodem (an ancient file transfer protocol) has had specified (but 
hopefully never implemented) options to execute commands on the client, i.e. 
it could do likely damage. Only imagine an internet where http , ftp, smtp, 
telnet, ssh, just any, would be allowed to do on the client side what the 
server side wants.... 

Same holds for the konsole, only perhaps, for a little less obvious reasons.

> You might try to post a clear and consist email to kde-devel mailing list
> and see if you get any replies/suggestions.

Yes, it is a bit unclear, what the problem is. Don't hesitate to write via 
private mail or keep posting on the list if you think it is a konsole or kde 
issue not properly understood by us.

-lars
_______________________________________________
konsole-devel mailing list
konsole-devel@kde.org
https://mail.kde.org/mailman/listinfo/konsole-devel