Why does redirecting 'script' to /dev/null/ allow 'screen' to work while su'ed as another user?

Question

I was su'ed into a user to run a particular long running script. I wanted to use screen but I got the error message "Cannot open your terminal '/dev/pts/4' - please check."

So I Googled around and came across a forum post that instructed to run $ script '/dev/null/'. I did so and then I could screen.

Why does this work? What is su doing that screen cannot run as the su'ed user? Why does re-directing 'script' to /dev/null do that is prevented otherwise? Is it using script to write a log as the original user to somewhere?

Solution 1

Well, technically you're not redirecting anything here.

Calling script /dev/null just makes script save the whole typescript into /dev/null which in practice means discarding the contents.

See man script for detailed info and util-linux-ng package for implementation (misc-utils/script.c).

This has nothing to do with screen actually. Why this works is invoking script has a side effect of creating a pseudo-terminal for you at /dev/pts/X. This way you don't have to do it yourself, and screen won't have permission issues - if you su from user A to user B, by directly invoking screen you try to grab possession of user A's pseudo-terminal. This won't succeed unless you're root. That's why you see the error message.

Solution 2

To output directly to your terminal window, the running program needs to be able to write to your controlling terminal. If you are using an xterm or ssh or some other virtual connection (as opposed to a real live directly connected terminal) your controlling terminal is a pseudo tty (pty).

Your pty is set up with write permission for only you when you log on, otherwise other users could scribble on your display (or read it). Thus when you su to another user (and that user is not root), that user does not have access to the underlying pty.

However, more complex I/O such as screen requires direct access to the pty to work it's magic of controlling your whole screen. That's when you run in to problems with the person running the command not having proper access to the controlling terminal.

Redirecting the script to /dev/null causes screen to not try to write to the controlling terminal, so it doesn't hit the permission problem.

Comments

[justarobert]

Cleaner would be to run su from within a screen session.

[Ashley]

@justarobert not if you want multiple users to be able to attach to that same screen for a service/batch-script-running account.

[Nanne]

"it", meaning screen output, doesn't go to /dev/null. First: script records your session (see the manpage), and you don't need it at all: so that goes to /dev/null. But it doesn have a side-effect: it makes a pseudo terminal, and now you are using this, and screen can write to this oneSee @karol-piczak 's anwer.