Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.shell
Subject: Re: Initiate command in another shell session?
Date: Fri, 14 Mar 2025 12:28:39 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vr17dn$h7e$1@reader1.panix.com>
References: <vquhba$3817f$1@dont-email.me> <87plikjz6j.fsf@nosuchdomain.example.com>
Injection-Date: Fri, 14 Mar 2025 12:28:39 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="17646"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 5110
Lines: 96

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.