No subject

> To leave the general consideration, what are the intended uses of the feature?
> When the feature was removed earlier, it was limited to send a 'cd Dir' (where
> Dir is a proper path name) to allow konqueror to control an embedded konsole,
> which clearly is much harder to abuse.

which is pretty useless though. A "cd DIR" is a pretty particular
demand, which may be done much nicer by giving konsole session a
specified working directory, e.g. in a profile or by giving "--workdir".

It still is a bad idea to whitelist just particular, what about a "cd
foo; rm -rf " for example or any given shell meta character? I still
don't think it should be konsole's responsibility to declare what are
"good" and "bad" commands for the underlying shell. Think about KDE on
Windows for example.

I think, in general there are very good reasons to allow DBus to send
keystrokes. We could, however, add an additional security layer, which
simply would ask the user if he wants to allow the sender to send
keystrokes. For example with a profile based user given whitelist, that way:

- Caller sends keystroke "apt-get upgrade"
- konsole asks the user "Caller wants to send 'apt-get upgrade' to your
terminal in window X. Allow that?
 [edit whitelist, e.g. specify wildcards]
 ( ) Yes, in that session only
 ( ) Yes (remember this setting)
 ( ) No (Don't ask again)

I think, Robert will be happily accept this patch, but I'd very unhappy
when removing that method. Of course this patch is just a solution for
that konsole problem, not resolving the (ab)use case for an attacker by
doing the almost the very same on the underlying X architecture.