Path: ...!weretis.net!feeder9.news.weretis.net!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: Thu, 13 Mar 2025 13:01:40 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: References: Injection-Date: Thu, 13 Mar 2025 13:01:40 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="16941"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Bytes: 6193 Lines: 114 In article , 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. 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.