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: References: <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 wrote: >Janis Papanagnou 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.