OS X Darwin: Disrupting Terminal Sessions Across User Identities

How, in Brief:

with cat < /dev/ttys_, in Terminal.

My Question

This OS X 10.9.2 Darwin behaviour seems odd to me, and I would like to understand why it is happening, and whether or not it is an actual OS or Application bug.

Steps to Reproduce Behavior

  1. open two Terminal windows.
  2. Note their device paths, i.e. "/dev/ttys001", "/dev/ttys002"
  3. In one Terminal window (i.e. /dev/ttys001), execute sudo -u [some other user] sh.
  4. In the other Terminal window (i.e. /dev/ttys002), execute cat < /dev/ttys001 (or whatever the device path is.)
  5. Back in the first window, type text.

Unexpected Behavior

When I type text in the relevant Terminal window, there is a noticeable lag; additionally, the characters do not appear reliably in either window. Some characters are echoed to the second window, some appear in the first window, and some seem to vanish.

Unexpected Consequences

The reason this concerns me is that it appears that a simple command executed by one unprivileged user can completely disrupt the session of another user.

Anticipated Possible Causes

  1. A text input bug in Terminal 2.4 (326)
  2. A user privledges bug in OS X 10.9.2 Darwin

2 Answers 2


3. A misunderstanding of what is going on.

You are not interfering with text sessions across user identities. Only a single user is running a session here, let's call her Alice. Alice is logged in on the console and running a bunch of applications, including some terminal emulators.

In one of these terminals, Alice executes sudo -u bob sh. Now there is a shell running under Bob's account, but the terminal is provided by Alice. The terminal emulator process is running as the user alice.

When you run cat /dev/ttys42 as Alice, you're snooping on, and even interfering with, the terminal emulator that is executed by Alice, not with the shell that is excecuted by Bob.

You're seeing weird phenomenon when you type because each byte is transmitted somewhat randomly to any of the processes that are reading input from the terminal. Normally there is only a single foreground process in a terminal: the job control mechanism and in particular the management of the foreground process group and the SIGTTIN signal ensure that.

Notice that /dev/ttys42 is owned by Alice. If Bob runs a terminal emulator, then /dev/ttys42 will be owned by Bob and not readable or writable by Alice, so Alice won't be able to interfere at that level. However, if this terminal is in Alice's GUI session, then Alice can interfere at the GUI level (e.g. by snooping on or injecting keystrokes, or by making Bob believe that he's interacting with the terminal he started when he's in fact interacting with an application executed by Alice).

  • Thank you. That was a superb answer. Comprehensive, falsifiable, articulate, and sourced.
    – muddletoes
    Mar 10, 2014 at 15:17

In order to write to a file, in this case a terminal, you need to have write permissions to it. By default, a tty file is owned (and writable) by the user who uses it, and also writable by the tty group, which again by default only contains root. So no, no messing with other people's sessions allowed.

  • Just to clarify the syntax, the 'intrusive' user session is reading from /dev/ttys001, rather than writing to it.
    – muddletoes
    Mar 9, 2014 at 23:00
  • Same thing, you don't have read permission on the ttys of other users. And actually, the tty group doesn't either.
    – fkraiem
    Mar 9, 2014 at 23:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .