Re: Initiate command in another shell session?

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.