1

Out of malicious curiosity I opened 2 terminals, each running the bash shell. In the first I type :

$ echo $$
11458

and in the second :

$ echo -n "echo this command" >> /proc/11458/fd/0

Then this text echo this command is indeed piped to the prompt on the first terminal. But on enter in that first terminal, that text is not executed as a command, I just get a new prompt.

In a second attempt, I executed this command in the first terminal:

$ read line;echo $line

and while the read is waiting for input, I again echo some text to /proc/11458/fd/0 in the second terminal. That text does appear on the first terminal, but on pressing <enter> in the first terminal, the read terminates, and the echo $line shows that no input was read.

So I still didn't find a way to do harm; all I can do is modify the text on the first terminal, from the second terminal. Screen readers on that first terminal of course, do pick this up. By screen readers I am thinking of mouse selection, or terminal functions like Save Contents ...; I tried both.

But if I knew how to also echo, for instance, an end-of-file or other control characters to the first terminal's stdin, couldn't I mess up things terribly for processes in the first terminal?

db-inf
  • 323

2 Answers2

5

Part 1 - does this answer your question? Writing to stdin of a process

Part 2 - you can write to (and read from) a terminal belonging to any process that you own. But standard UNIX permissions will prevent you writing to (or reading from) any device that's associated with a different user login.

ls -l /proc/$$/fd/0
lrwx------ 1 roaima roaima 64 Nov 27 13:19 /proc/7859/fd/0 -> /dev/pts/0

ls -lL /proc/$$/fd/0
crw--w---- 1 roaima tty 136, 0 Nov 27 13:24 /proc/7859/fd/0

I can write to this device:

( tput smso; echo 'surprise!' ) >/dev/pts/0
Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • On your Part 1, I actually did read that question before daring mine. I looked up the TIOCSTI you commented on there, and it hightened my fear, because Simulate terminal input is exactly what seems dangerous to me. Gilles 'SO- stop being evil' too had in his anser the possibility If /proc/PID/fd/0 is a pipe, then writing to it appends the data to the pipe's buffer. In that case, the process that's reading from the pipe will read the data. And then in the accepted answer the stdX are linked to /dev/pty#, mine to /dev/pts/#. – db-inf Nov 29 '21 at 09:25
  • On your Part 2. What you are saying, is that when I mess up, it's my own authorized mess. Thanks for the reassurance. The problem is that I am also the root of my private personal computer, and a linux newbie. – db-inf Nov 29 '21 at 09:30
  • Db-inf generally it's better not to run day to day as root. Very little will stop you doing so, because it's your mschine, but it's better to do stuff as a normal user for as much of the time as possible – Chris Davies Nov 29 '21 at 09:43
  • 1
    Don't worry. Also is not a synonym of always. – db-inf Nov 29 '21 at 19:47
2

This may be an easy explanation:

If a terminal process writes to the terminal (stdin, stdout, and stderr all point to the same device/pty), then this output does not become its next input. Obviously.

echo foo

does not have the same effect as typing fooenter.

So why would a different process writing to the terminal become another processes terminal input? Doesn't make any sense.

In contrast to a file, with a (pseudo) terminal the data written to and read from it are not related because the data source is something completely different (a keyboard or a program). See man 7 pty. A pseudo terminal has a client side which is used by the terminal applications and a master side where the input for the client side is generated.

My terminal emulator is konsole (PID 40818), currently running only one shell/terminal:

start cmd:> ll /proc/40818/fd
insgesamt 0
lr-x------ 1 hl hauke 64 27. Nov 15:06 0 -> 'pipe:[1177680901]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 1 -> 'socket:[89302]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 10 -> /dev/dri/renderD128
lrwx------ 1 hl hauke 64 27. Nov 15:06 11 -> /dev/dri/renderD128
lrwx------ 1 hl hauke 64 27. Nov 15:06 12 -> /dev/dri/renderD128
lrwx------ 1 hl hauke 64 27. Nov 15:06 13 -> /dev/dri/renderD128
lrwx------ 1 hl hauke 64 27. Nov 15:06 18 -> /dev/ptmx
lrwx------ 1 hl hauke 64 27. Nov 15:06 19 -> /dev/pts/40
lrwx------ 1 hl hauke 64 27. Nov 15:06 2 -> 'socket:[89302]'
l-wx------ 1 hl hauke 64 27. Nov 15:06 21 -> 'pipe:[1177664260]'
lr-x------ 1 hl hauke 64 27. Nov 15:06 28 -> 'pipe:[1177664264]'
l-wx------ 1 hl hauke 64 27. Nov 15:06 29 -> 'pipe:[1177664264]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 3 -> 'socket:[1177673938]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 4 -> 'anon_inode:[eventfd]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 5 -> 'anon_inode:[eventfd]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 6 -> 'socket:[1177650969]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 7 -> 'anon_inode:[eventfd]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 8 -> 'socket:[1177677086]'
lrwx------ 1 hl hauke 64 27. Nov 15:06 9 -> 'socket:[1177677087]'

ec:0   15:06:36  hl@monster:~
start cmd:> tty
/dev/pts/40

You can see, the shell uses /dev/pts/40 but the terminal emulator writes to /dev/ptmx. Only the file descriptor 18 of the terminal emulator can write to the input of /dev/pts/40. If a different process opens /dev/ptmx then it creates a new pseudo terminal to which is written to.

Hauke Laging
  • 90,279
  • I cannot directly connect the /dev/pts/40 and /dev/ptmx you mention, to your stdin and stdout; are the latter still filedescriptors 0 and 1? But the first part of your answer makes sense to me. Until 30 years ago I programmed low-level MS-DOS programs, and I remember something about the difference between hooking to the keyboard interrupt, and reading from the keyboard buffer. And I recollect that in C you had to be consistent about using either putc and it's relatives, or putchar. So I accept your answer as sufficient to take away my fears. – db-inf Nov 29 '21 at 09:50
  • Yes, stdin and stdout are still 0 and 1. I have no problem connecting to them (except for the fact that two shells reading from the same pty simultaneously leads to strange results). I execute tty in a different terminal and get /dev/pts/11. Then I run (elsewhere): bash -c 'echo $$; exec 0</dev/pts/11;cat' – Hauke Laging Nov 29 '21 at 15:00