Re: Initiate command in another shell session?

In article <87plikjz6j.fsf@nosuchdomain.example.com>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

The question occurred to me whether it would be possible to remotely
execute a command as if started from another shell session *in* that
shell session.
>
My first thought was that it might be an undesirable property (if only
for "security reasons", or more likely, generally).
>
What I can do is
* sending some data to another shell session, say,
    ls > /dev/pts/22
* get the output of a command executed on another host, say,
    ssh somehost ls
* send the output of a remote execution to another shell, say,
    ssh somehost ls > /dev/pts/22
>
Note that the latter will not operate in the shell context of the shell
session that is running on somehost with /dev/pts/22.
>
I guess the answer to my question is simply "no", but I'd like to have
a confirmation (and possibly more specific rationales or remarks).
>
Janis
>
PS: On an old SunOS 4 SPARC system I was (without privileges) able to
even change the remote users system characteristics (like mouse speed),
but I suppose that must be considered a security issue on that platform.

>
Writing to a tty is easy, if you have the right permissions.
Pushing text input into a tty so it behaves as if it had been typed
is trickier, and not necessarily possible
>
On some systems, opening a tty and calling ioctl(fd, TIOCSTI, ptr),
where ptr is a char*, will cause the single character *p to appear
as if it had been typed.  This might not work for a tty other than
the current stdin, and it's started requiring root access in recent
Ubuntu releases.

Fortunately, these systems are becoming fewer and farther
between; TIOCSTI seems cool, but is a horrible security risk,
particularly given the historical Unix behavior where a process
that had no controlling terminal device and opened a tty would
become associated with that tty.

At a previous job several decades ago, we had a command `typein`
that used this mechanism.  In most cases, I've found `eval` to be
a cleaner way to do what I was using `typein` for.
>
Emacs uses this mechanism for the `suspend-emacs` function:
>
   (suspend-emacs &optional STUFFSTRING)
   ...
   If optional arg STUFFSTRING is non-nil, its characters are stuffed
   to be read as terminal input by Emacs’s parent, after suspension.
   ...
   On some operating systems, stuffing characters into terminal input
   buffer requires special privileges or is not supported at all.  On
   such systems, calling this function with non-nil STUFFSTRING might
   either signal an error or silently fail to stuff the characters.
>
You can do this with tmux, which allocated and controls a pty for each
window.  For example:
>
   echo echo hello world | tmux load-buffer -
   tmux paste-buffer -t 1
>
This causes the pane named "1" to act as if you had typed "echo
hello world" into it.  You can use a named buffer ("-b TEMP") if
you don't want to step on the default one, and delete the buffer if
you don't want to keep the text (I sometimes use this for passwords).

I would imagine tmux handles this differently: the canonical way
to provide input data to a pseudoterminal is to write to the
"master" end of a master/slave pseudo-tty pair; but while the
slave end is usually named in the filesystem, the master side is
not; but note that the tmux server process has access to that
for every TTY.  So I'd imagine that the `tmux paste-buffer`
mechanism would just write to the FD for the master side of the
pair.

Of course if the target pane doesn't happen to be sitting at a shell
prompt, odd things can happen.
>
I don't know whether GNU screen has a similar feature.

I don't know the specific answer here, but you could drive a
screen session with something like `expect`.

Certainly, a session manager like tmux, screen, zellij, or
whatever would be a way to address this issue, and lots of
people do run those locally.  But you've got to remember to do
it.

- Dan C.