From Newsgroup: comp.unix.shell

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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <vquhba$3817f$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

I don't think I understand what you mean. Do you mean that you
would be able to hijack a user's TTY in order to run commands on
some other system (e.g., via `ssh` or something) as them?

My first thought was that it might be an undesirable property (if only
for "security reasons", or more likely, generally).

Yeah, that seems bad.

What I can do is
* sending some data to another shell session, say,
ls > /dev/pts/22

Well, I'd phrase this as, you're writing data to some terminal
device. Whether there's a shell running it in, or not, is
irrelevant. Of course, to be able to do this, you have to have
write permissions to that `/dev/pts/22`.

This is fundamentally how tools like `write` work.

* 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

Sure. Here, you're just writing data to that pty. Suppose
there is a user logged into it, and they're sitting in front of
a terminal; what they would see is the output from ls, executed
by you on "somehost", appear on their terminal.

Note that the latter will not operate in the shell context of the shell >session that is running on somehost with /dev/pts/22.

This is the part where I'm not sure what you mean. You are
executing a command on "somehost"; in this case, `ls`. But you
are redirecting output to the _local_ `/dev/pts/22` (again,
assuming you have write permissions to that device). That is,
the `ssh` command is running on the same system where you are
writing to `/dev/pts/22`, and the `ssh` client command has its
standard output connected to that pty device; whatever runs on
"somehost" as a result of you running `ssh` is happening on that
system, as invoked by the SSH server, that has no knowledge of,
or interest in, how the client is configured with respect to its
IO configuration, let alone local ptys: that is, the distant
end, assuming that "somehost" is a distinct system other than
the one you're doing all of this on, has no access to the state
of the local pty devices on the source end. Indeed, given
the way that you've run this, `ls` on "somehost" is likely not
assocaited with any terminal device at all.

If instead you had run:

ssh somehost 'ls > /dev/pts/22'

Then you would be writing to `/dev/pts/22` on the distant end,
not locally.

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).

I'm still not sure what you're asking.

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.

I no longer recall how such things were controlled on SunOS 4,
but I imagine that you opened a device file and issued an ioctl
to control things like that. What this suggests to me is that
you were able to connect to some remote machine where the device
files in question were permitted so that you could open them and
issue those controls. Had they had more restrictive permissions
(say 0600 and owned by the logged-in user) then I suspect you
would not have been able to do that. But there were bugs in
SunOS 4, which came from a simpler time, so perhaps I'm wrong.

I do recall once crashing my boss's workstation by accident: his
name was Dave, and we found some audio clips in Sun audio format
of HAL from the movie "2001" saying, "I'm sorry, Dave, I can't
let you do that..." or "why don't you sit back, relax, and take
a stress pill..." and were having fun rsh'ing into his machine
and `cat`'ing them into `/dev/audio` there (so they played on
the builtin speaker, which of course was in his office. Note
that we could only do this because we had write access to the
audio device; we also had root access, so he couldn't depermit
it).

Anyway, we would do that, and get a file playing, and he'd kill
the process writing to the audio device, and the speech would
stop. So we kept escalating by trying newer, more creative ways
to buffer the audio data in the kernel before we he could kill
off the writing process. It seems we took this a little too far
though, as I tripped a bug in the audio driver (I think a NULL
op in the cdevsw used by some system call we were using that
wasn't implemented by the driver; the details are fuzzy now) and
it crashed his machine. I didn't realize this had happened, but
we all also ran little programs that `tail -f`'d the more
important log files consolidating important events from around
our network. So I saw his workstation rebooting and thought I'd
been so clever that the only way he could stop HAL was by
rebooting. Then I saw him log into my machine, which suddenly
rebooted. "Hey! What'd you do that for?!" I shouted across the
hall. "You did it to me!" he responded.

Of course, this was all in good fun, but we stopped trying to
prank each other with random audio files after that.

- Dan C.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

I'll split my response on the two topics, because they got lengthy.
Here's the first... (concerning a SunOS 4 issue and similar)

On 13.03.2025 14:01, Dan Cross wrote:

In article <vquhba$3817f$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

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.

I no longer recall how such things were controlled on SunOS 4,
but I imagine that you opened a device file and issued an ioctl
to control things like that. What this suggests to me is that
you were able to connect to some remote machine where the device
files in question were permitted so that you could open them and
issue those controls. Had they had more restrictive permissions
(say 0600 and owned by the logged-in user) then I suspect you
would not have been able to do that. But there were bugs in
SunOS 4, which came from a simpler time, so perhaps I'm wrong.

Actually I cannot recall the details from back these days. All I
can say is that we were able (without root access) to change some
configuration file on the target machine only by means available
through shell and with the tools available to run jobs remotely
on the distributed client systems. (We might have had root access
on our own workstation but I'm not sure about that.)

(For our long lasting simulation processes the department policy
was to be able to run software on other's Sun workstations to use
their CPU capacity overnight, when they were unused, or low on CPU
load.)

We couldn't believe that this was possible, though, to change the
hardware characteristics so easily, without effort and without any
special tools or privileges on the remote machines.

We set up an experiment (call it joke), creating a cronjob to do
that change temporarily; every hour we accelerated the mouse speed
of the remote systems for a few seconds only. We didn't think that
this would get noticed at all - most people in science used mostly
the keyboard and rarely the mouse. Alas, we produced sort of panic! Unfortunately my colleague and me, the "experimenters", were a day
off, and when we came back we heard that they thought to have some
security attack - and I have to admit, even if not intended as one,
it actually turned out to be one. And they intended to reboot all
systems (or even reinstall? don't recall), which of course would
not have fixed that behavior. (Needless to say that we instantly
deactivated that cronjob.)

I also think that this type of security issue would also be hard
to localize if you'd look only onto the target machines.

I do recall once crashing my boss's workstation by accident: his
name was Dave, and we found some audio clips in Sun audio format
of HAL from the movie "2001" saying, "I'm sorry, Dave, I can't
let you do that..." or "why don't you sit back, relax, and take
a stress pill..." and were having fun rsh'ing into his machine
and `cat`'ing them into `/dev/audio` there (so they played on
the builtin speaker, which of course was in his office. Note
that we could only do this because we had write access to the
audio device; we also had root access, so he couldn't depermit
it).

Our primary system administrator did that as well. After lunch he
invited us to the coffee break in his office by sending us an (coffee-)advertisement recording through the audio device. Imagine
such a distributed sound effect coming from every office on the
floor in parallel like a symphony (but less highbrow, more thin
brew like typical US coffee - sorry for the pun).

Anyway, we would do that, and get a file playing, and he'd kill
the process writing to the audio device, and the speech would
stop. So we kept escalating by trying newer, more creative ways
to buffer the audio data in the kernel before we he could kill
off the writing process. It seems we took this a little too far
though, as I tripped a bug in the audio driver (I think a NULL
op in the cdevsw used by some system call we were using that
wasn't implemented by the driver; the details are fuzzy now) and
it crashed his machine. I didn't realize this had happened, but
we all also ran little programs that `tail -f`'d the more
important log files consolidating important events from around
our network. So I saw his workstation rebooting and thought I'd
been so clever that the only way he could stop HAL was by
rebooting. Then I saw him log into my machine, which suddenly
rebooted. "Hey! What'd you do that for?!" I shouted across the
hall. "You did it to me!" he responded.

Of course, this was all in good fun, but we stopped trying to
prank each other with random audio files after that.

Thanks for sharing that story.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 13.03.2025 14:01, Dan Cross wrote:

In article <vquhba$3817f$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

I don't think I understand what you mean. Do you mean that you
would be able to hijack a user's TTY in order to run commands on
some other system (e.g., via `ssh` or something) as them?

Actually that question arose after a necessary reboot of my system,
which had shown a strange effect[*] and was unusable. - I wanted to
obtain from my shell sessions some information, and since I happen
to have dozens of shell windows open in parallel - and I considered
it boring to go through all virtual windows with all it's individual
shell windows - I thought about starting that request on each window
uniquely from one shell window. That's how it started why I pondered
about the question and tried a couple things.

So, no; no hijack intended, no other users concerned. (I'm the only
user on my system, or so I hope.) It was at that point actually an
academical question.

My first thought was that it might be an undesirable property (if only
for "security reasons", or more likely, generally).

Yeah, that seems bad.

What I can do is
[...]

Note that the latter will not operate in the shell context of the shell
session that is running on somehost with /dev/pts/22.

This is the part where I'm not sure what you mean. You are
executing a command on "somehost"; in this case, `ls`.

I used the "somehost" just as describing the general case for using
these remote tools. In my case I actually used 127.0.0.1 (localhost)
for the test case I was interested in.

But you
are redirecting output to the _local_ `/dev/pts/22` (again,
assuming you have write permissions to that device). That is,
the `ssh` command is running on the same system where you are
writing to `/dev/pts/22`, and the `ssh` client command has its
standard output connected to that pty device; whatever runs on
"somehost" as a result of you running `ssh` is happening on that
system, as invoked by the SSH server, that has no knowledge of,
or interest in, how the client is configured with respect to its
IO configuration, let alone local ptys: that is, the distant
end, assuming that "somehost" is a distinct system other than
the one you're doing all of this on, has no access to the state
of the local pty devices on the source end. Indeed, given
the way that you've run this, `ls` on "somehost" is likely not
assocaited with any terminal device at all.

I used 'ls' just as an example to show that the remotely executed
program needs shell context information from that remote terminal
since each shell window will reside in an own working directory.

(Note: In my environment I actually can get that $PWD information
after a reboot because I have set it up to memorize that for each
shell window. But a shell session has yet more context, and, as
said, it was a principle academic question at that point whether
it was doable in the first place or prohibited or impossible by
other principle factors.)

If instead you had run:

ssh somehost 'ls > /dev/pts/22'

Then you would be writing to `/dev/pts/22` on the distant end,
not locally.

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).

I'm still not sure what you're asking.

I hope it got clearer from the additional information.

[ SunOS stuff answered in previous post ]

Janis

[*] Something I never noticed before, BTW. - My CPU% was at "0%",
not even the typical high basis load of Firefox was displayed. The
whole window manager stuff (mouse movement, menu item selection,
change of virtual sessions, switch to plain non-WM consoles, some
tools in the task-bar like the clock was still counting, etc.) was
working, though, but not a single (other) command got executed;
not even a new cursor shown when hitting <Enter> in a shell window.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-03-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

The target shell session has to run some service loop listening for
these requests, on a pipe or something.

On top of that you can build remote procedure calls.

Running any command specified by the caller is equivalent to having
"eval" available as a remote procedure call.

Or something lesser: running any simple command (command name
with arguments). When the function unpacks the arguments,
it can subject them to some validation, checking for allowed
commands or command/argument combinations.

About the service loop, we don't have threads in the popular
shells like Bash.

If it's all one the same machine, you could set a trap for a
signal in the target shell. Then when the caller deposits a
message in the message box (however that is implemented)
it kills that shell with the signal. The trap handler will
then dispatch the RPC.

If the target shell is interactive, you might want it so that
the commands are not immediately dispatched while that shell
is executing code, only when it's ide. (And by the way, when the shell
is suspended waiting for an external command, like an editor to exit, it
won't be able to take RPCs).

The trap handler can check a global flag indicating whether the
shell is idle (OK to dispatch command now) or busy (queue
the command, to be run when it goes out of the busy state).

As you can guess, my thinking here is influenced by having
worked on the Basta extension, which updates the status line
in response to timer signals.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <vqv1c0$3gq75$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 13.03.2025 14:01, Dan Cross wrote:

In article <vquhba$3817f$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

I don't think I understand what you mean. Do you mean that you
would be able to hijack a user's TTY in order to run commands on
some other system (e.g., via `ssh` or something) as them?

Actually that question arose after a necessary reboot of my system,
which had shown a strange effect[*] and was unusable. - I wanted to
obtain from my shell sessions some information, and since I happen
to have dozens of shell windows open in parallel - and I considered
it boring to go through all virtual windows with all it's individual
shell windows - I thought about starting that request on each window
uniquely from one shell window. That's how it started why I pondered
about the question and tried a couple things.

So, no; no hijack intended, no other users concerned. (I'm the only
user on my system, or so I hope.) It was at that point actually an
academical question.

I think I understand; let me paraphrase, and tell me if I'm
correct?

I think you're asking if you can write to a terminal device, and
have what you write be treated as input data for whatever
program is running on that tty/pty; is that right? And then, if
that is possible, whether you can do this over the network?

So that, for example, if you have a terminal emulator with a
window that is running some shell process, controlled by some
pty device, you could execute a command on that computer over
the network that would get the shell running in that window
run some command?

If that's correct, then the answer, generally is no: you can't
do that. If you open the pty device associated with that shell,
you're and write to it, you're really writing to the same
output that the shell process is connected to, not it's input.

There's no simple way to interpose onto the input stream.

My first thought was that it might be an undesirable property (if only
for "security reasons", or more likely, generally).

Yeah, that seems bad.

What I can do is
[...]

Note that the latter will not operate in the shell context of the shell
session that is running on somehost with /dev/pts/22.

This is the part where I'm not sure what you mean. You are
executing a command on "somehost"; in this case, `ls`.

I used the "somehost" just as describing the general case for using
these remote tools. In my case I actually used 127.0.0.1 (localhost)
for the test case I was interested in.

[snip]

I used 'ls' just as an example to show that the remotely executed
program needs shell context information from that remote terminal
since each shell window will reside in an own working directory.

Sure. But it doesn't really change things, if what I wrote
above is correct vis understanding what you're getting at.

(Note: In my environment I actually can get that $PWD information
after a reboot because I have set it up to memorize that for each
shell window. But a shell session has yet more context, and, as
said, it was a principle academic question at that point whether
it was doable in the first place or prohibited or impossible by
other principle factors.)

Yeah. Note that working directory is inherited through an exec.
So the terminal emulator, when it goes to run a shell, can
arrange to chdir into an arbitrary directory before in the
process it creates before it exec's the shell. That's how that
part works.

If instead you had run:

ssh somehost 'ls > /dev/pts/22'

Then you would be writing to `/dev/pts/22` on the distant end,
not locally.

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).

I'm still not sure what you're asking.

I hope it got clearer from the additional information.

If my understanding of what you're getting after above is
correct, then yes.

[ SunOS stuff answered in previous post ]

[*] Something I never noticed before, BTW. - My CPU% was at "0%",
not even the typical high basis load of Firefox was displayed. The
whole window manager stuff (mouse movement, menu item selection,
change of virtual sessions, switch to plain non-WM consoles, some
tools in the task-bar like the clock was still counting, etc.) was
working, though, but not a single (other) command got executed;
not even a new cursor shown when hitting <Enter> in a shell window.

Are you sure the issue wasn't with your keyboard? I'd have
maybe tried to disconnect and reconnect it.

- Dan C.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Thu, 13 Mar 2025 07:59:29 -0400, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

Yes, it can be done using vnc. The mouse and keyboard can be taken over, with the video
displayed both locally and remotly.

I used it in the past when first introducing my brother in-law to linux. He has never had any
classroom or on line computer training, and struggles with the basics. He was quite surprised
when I moved my mouse and the pointer on his screen moved, and I was able to open a
konsole session, on his screen and type commands into it, or move the mouse pointer to
open the menu and select a program to execute.

Regards, Dave Hodgins
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-03-13, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

The short answer is "no".

The slightly longer answer: Sure, if that shell offers an interface
that a remote process can send commands to and which the shell then
executes. In reality, shells don't offer this.

The closest thing might be tmux(1), where you can attach to a remote
session and interact with it in various ways.
http://tmux.github.io/
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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.

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 EmacsrCOs 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).

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.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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.

I used this in a Superuser Stackexchange answer, the C code from
which can be used as a sample.

https://superuser.com/questions/272818/how-to-turn-off-word-wrap-in-less/#1871997

What's such a thing doing on Superuser? It's part of trying to address
a usability quirk with the "less" pager, in a really hacky way.

I cobbed a solution together whereby we filter the to-be-paged text to
add a certain number of spaces to the start of every line, and then we
tell less to scroll to the right by exactly that many positions.

How we do that last step is by injecting the right arrow escape sequence
via TIOCSTI. (A small delay is required, so that this injection happens
after less has done its terminal initialization.)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 13.03.2025 19:25, Dan Cross wrote:

In article <vqv1c0$3gq75$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

[...]

I think I understand; let me paraphrase, and tell me if I'm
correct?

[...paraphrase snipped...]

Yes, that was correct.

If that's correct, then the answer, generally is no: you can't
do that. If you open the pty device associated with that shell,
you're and write to it, you're really writing to the same
output that the shell process is connected to, not it's input.

There's no simple way to interpose onto the input stream.

My unformed thoughts went along the line of how a pty intercepts
communication to a process, probably combined with an attachment
to a process (as I recall you can attach a debugger to a running
process).

[...]

[*] Something I never noticed before, BTW. - My CPU% was at "0%",
not even the typical high basis load of Firefox was displayed. The
whole window manager stuff (mouse movement, menu item selection,
change of virtual sessions, switch to plain non-WM consoles, some
tools in the task-bar like the clock was still counting, etc.) was
working, though, but not a single (other) command got executed;
not even a new cursor shown when hitting <Enter> in a shell window.

Are you sure the issue wasn't with your keyboard? I'd have
maybe tried to disconnect and reconnect it.

I'm pretty sure it wasn't the keyboard(s). (At least I see no way
how it should have influenced that extreme effect. Both keyboards
are firmly attached, they worked smoothly many years, and still
did their job after the system restarts.) It could of course have
been some OS component handling the keyboards in principle, but
all the above described accompanied effects that I observed are
also unrelated to the keyboard. So at best very unlikely I'd say.
Anyway. After the reboot everything was fine, so I don't make my
mind about it. It was just something I've never observed before;
typically, if anything, my window manager (or other long running
processes) show problems occasionally after long uptimes, while
the rest works smoothly, but this time... just strange (to me).

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 13.03.2025 12:59, Janis Papanagnou wrote:

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
[...]

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).

I'll followup my own post to thank all repliers for their thoughts
and suggestions in a single reply.

Just to clarify, the question was meant to operate on the running
system (sort of "on top") as it is, without changing or preparing
the already running components. In a recent post I explained my
thoughts by...

"My unformed thoughts went along the line of how a pty intercepts
communication to a process, probably combined with an attachment
to a process (as I recall you can attach a debugger to a running
process)."

This probably doesn't work - I'm not sure, and I haven't pondered
about it long enough - but that uncertainty was why I was asking
for thoughts, ideas, hints, remarks.

Janis

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

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 EmacsrCOs 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.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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.

I associate TIOCSTI with csh(1)'s filename expansion feature, but
a look at the BSD history shows that the introduction of the ioctl
precedes the csh feature there by three years--1980 and 1983,
respectively.

This might not work for a tty other than
the current stdin, and it's started requiring root access in recent
Ubuntu releases.

OpenBSD has dropped TIOCSTI completely a number of years ago.
*checks history* Functionality neutered in 2017, removed in 2018.
"Due to risks known for decades", says the commit message.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-03-14, Christian Weisgerber <naddy@mips.inka.de> wrote:

On 2025-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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.

I associate TIOCSTI with csh(1)'s filename expansion feature, but

Seriously? Is this what I think it is: that csh tromboned out characters
to the TTY driver to get the OS to type in the expansion as if the user
typed it?

Wow, ... I see considering only csh *programming* to be harmful was
an overly optimistic view.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-03-14, Kaz Kylheku <643-408-1753@kylheku.com> wrote:

I associate TIOCSTI with csh(1)'s filename expansion feature, but

Seriously? Is this what I think it is: that csh tromboned out characters
to the TTY driver to get the OS to type in the expansion as if the user
typed it?

I think so. The key here is that csh does not implement a command
line editor. It relies on the cooked mode processing of the standard
tty line discipline. It needs to feed the expansion results in
there as if they had been typed, so actions like character/word/line
erase can be performed.

Wow, ... I see considering only csh *programming* to be harmful was
an overly optimistic view.

static char *sccsid = "@(#)file.c 1.1 (Berkeley from Hp Labs) 11/02/83";

/*
* Tenex style file name recognition, .. and more.
* History:
* Author: Ken Greer, Sept. 1975, CMU.
* Finally got around to adding to the Cshell., Ken Greer, Dec. 1981.
*/
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-03-13 at 15:25 ADT, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <vqv1c0$3gq75$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 13.03.2025 14:01, Dan Cross wrote:

In article <vquhba$3817f$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

I don't think I understand what you mean. Do you mean that you
would be able to hijack a user's TTY in order to run commands on
some other system (e.g., via `ssh` or something) as them?

Actually that question arose after a necessary reboot of my system,
which had shown a strange effect[*] and was unusable. - I wanted to
obtain from my shell sessions some information, and since I happen
to have dozens of shell windows open in parallel - and I considered
it boring to go through all virtual windows with all it's individual
shell windows - I thought about starting that request on each window >>uniquely from one shell window. That's how it started why I pondered
about the question and tried a couple things.

So, no; no hijack intended, no other users concerned. (I'm the only
user on my system, or so I hope.) It was at that point actually an >>academical question.

I think I understand; let me paraphrase, and tell me if I'm
correct?

I think you're asking if you can write to a terminal device, and
have what you write be treated as input data for whatever
program is running on that tty/pty; is that right? And then, if
that is possible, whether you can do this over the network?

So that, for example, if you have a terminal emulator with a
window that is running some shell process, controlled by some
pty device, you could execute a command on that computer over
the network that would get the shell running in that window
run some command?

If that's correct, then the answer, generally is no: you can't
do that. If you open the pty device associated with that shell,
you're and write to it, you're really writing to the same
output that the shell process is connected to, not it's input.

There's no simple way to interpose onto the input stream.

If the terminal has the "feature" that you can cause it to echo back a
string (thus seen as stdin) by writing the string to the terminal and
wrapping it with the appropriate control sequence, then you can put your
data into the input stream. (I used this a long time ago as a
counter-measure to a particular system's admin policy that if you didn't
touch the keyboard for some amount of time they would log you off the
system. I ran a program which wrote the special string to the terminal,
and the terminal sent a char up the line, making the system think I was entering data.)

This depends on the terminal in use, and may not satisfy your definition of "simple".

Cheers.
Jim
--- Synchronet 3.21b-Linux NewsLink 1.2