Nitpicking the shell history scene in ‘Tron: Legacy’

This was the very first thing that jumped out at me when
I first watched this film and paused the DVD. Sam requests
the shell history by running bin/history
instead of just history. Why?

I can’t see any possible way that makes sense on real
Unix. Shell history is stored in data structures inside
the shell process itself, so the history
command must be a shell builtin, in order to read out
those structures. Even if you only wanted to read out the
version of the history stored in a disk file, the name and
location of that file varies with the shell and its
configuration, so an external command that
did that would still be very difficult to get
right.

My conclusion at the time – and it still seems fairly
plausible to me now – is that this is revealing the
technique the filmmakers used to present their fake
plot-related shell history. (Like an accidental visible
wire, in wire-fu.) I think this shell session was
generated by typing commands into a real, carefully
configured, Unix machine, and bin/history was
a simple shell script that prints that history in
place of whatever more boring thing existed in the real
shell.

(Note, in particular, that the history doesn’t end with
the command bin/history! When you run a real
shell history command, generally the output ends with the
very history command you just typed, because
it’s been inserted into the history list before the
history list is read back out.)

Supposing I’m right, this could have been done better, by
wrapping the history shell builtin with an
alias or function. Then the user could have typed
plain history, and it still could have been
made to produce this carefully constructed output.

(The same argument doesn’t apply to other commands Sam
types in this session, like uname, because
those aren’t shell builtins: they’re found
on PATH, so you can override them by putting
your own directory earlier on PATH. So my
guess is that whoever set up this scene knew how to do
that, but didn’t know how to do aliases.)

The first thing Sam sees is a shell prompt, not a login
prompt: Flynn had left himself logged in. So he starts by
running whoami, to determine who he was
logged in as. The computer
prints flynn, presumably an unprivileged user
account. That’s no good – Sam knows he’s going to need to
be root to investigate properly. He tries to log in
as root, but fails, so he
tries backdoor instead, which succeeds.

A natural question is: if root
and backdoor are separate accounts, isn’t he
about to list the shell history from the wrong one? Surely
Flynn was logged in as root to do whatever he
was doing.

But we can see that the backdoor account has
user id 0, the same as root, because after
Sam successfully logs in as backdoor, the
shell prompt is a # instead of
a $. That typically happens when the shell
detects that it’s running as the root uid.
So backdoor and root share a
uid, and so it’s reasonable to guess that they share a
home directory and shell history too.

We also see that backdoor’s home directory
is taken by login to be the VFS
root, /, because nothing better is specified
in /etc/passwd. So presumably the shell just
read a history file from the VFS root: something like
/.bash_history, or at
least /.something_history (I don’t
think there’s much evidence of exactly what shell this
is). It’s fairly plausible that root also has
its home directory set to /; that’s not the
default on Linux, which gives root a proper
home directory of its own, but it was certainly pretty
common on proprietary Unixes I used in the 1990s.

So that all hangs together: Flynn ran those commands
as root, and by a slightly roundabout route,
Sam might indeed have logged in to an account that can
list them in a natural way.

(I’m also a bit suspicious of the use
of login to switch user from within an
existing login session; one would expect
perhaps su? To do this
job, /bin/login would need to be setuid, and
it certainly isn’t on Linux – it expects to be invoked by
programs like getty or
(historically) telnetd, which are already
root when they run it. Perhaps Solaris (or
SolarOS) is different? But it seems unlikely.)

Finally, why is there a backdoor account
anyway? Normally you make one of those if you have access
to a system but are worried that someone will try to take
that access away from you (and are unscrupulous). A hacker
worried their original entry route will be closed off, or
one of the people with root on a system, worrying that the
other(s) will take their access away. In this case, it’s
Flynn’s own machine; who was he expecting to lock him out
of it, to need a back door to get back in?

We could simply appeal to Scriptwriters’ Shortcuts:
sometimes systems have back doors, so you can assume there
is one if the plot requires it, and nobody needs to
provide an in-world explanation. But we
mostly haven’t had to use that kind of non-answer
in this exercise, so I’d rather not. I think a perfectly
good in-world explanation is that Sam made the
back door, without his dad’s knowledge. Perhaps Flynn
trusted his son with root on the same machine (plausible
– my dad trusted me, when we shared a Linux
system), but Sam had some reason to suspect that Flynn was
becoming secretive and mysterious, and anticipated that
Flynn might close off the root account to try to hide what
he was up to. And it looks as if that did happen,
because we can see that Sam initially expected to
be able to log in as proper root, and only
used the back door once he found he couldn’t do that.
Apparently he knew his father well, and was right to
suspect!

Another initial investigatory command Sam runs
is uname -a, to check exactly what kind of
Unix system he’s looking at. You could imagine that that
might change his choice of subsequent commands to type, if
he’s enough of a Unix generalist to know which OSes spell
which detailed things differently.

The operating system name printed by uname
is “SolarOS”. That’s not a real OS name, but it looks a
lot like a mixture of SunOS and Solaris,
two names for the range of proprietary Unixes from Sun
Microsystems. I speculate that the very slight change of
name might have been deliberate, to avoid a trademark
quibble from Sun?

The appearance of sun4m later in
the uname output supports this theory. And
the overall format of the uname string is
pretty close to real Solaris examples I found on web pages
(alas, I don’t have access to an actual Solaris machine to
check with). I found this, for example, on one web page:

# uname -a
SunOS storage1 5.10 Generic_125101-09 i86pc i386 i86pc

That Generic_125101-09 is a pretty close
match to the Generic_50203-02 in the film;
I’d guess it’s something like the kernel version number.
The rest is fairly close too (although the host name
field storage1 in the real output seems to
have no analogue in the film version). So it looks as if
this is supposed to be a depiction of a
(prudently renamed) Solaris.

However, the shell windows on the left make this look
like a superficial imitation! The top left shell window is
showing the output of top in exactly the
Linux style, and not only that, the list of process names
down the right-hand column is characteristically Linuxish.
Even though we can only see the first four letters of each
process, we can see things that look suspiciously
like kthreadd, scsi_eh_something, migration, ksoftirqd,
and watchdogd. All of those are process names
internal to the Linux kernel. Meanwhile, the bottom left
window is showing what looks like the output
of iostat, and again, it looks much more like
the Linux style of iostat than the Solaris
style.

So I think this is supposed to be a Solaris
machine, within the story – but the actor playing the part
is a Linux machine, and the costume and makeup department
missed a few bits.

Also, I think the appearance
of both sun4m and i386
in the uname output is another goof. Solaris
does run on x86 hardware, but sun4m is a
class of SPARC-based hardware. The real
Solaris uname output I show above prints the
identifier i86pc in the ‘platform name’ slot
where the film had sun4m.

Another hint of Linux is the cat
/proc/meminfo in the shell history on the right. As
far as I can tell from Solaris man pages on the web,
Solaris does have a /proc special
filesystem, but it’s not exactly like Linux’s, and in
particular, doesn’t have meminfo or anything
like it. (In fact, from the man pages I found,
the only things that live in
Solaris /proc are numbered directories
corresponding to running processes, and
the self symlink.)

When I paused the DVD while watching the film, I
immediately noticed that there were three
commands make, make install, and
(after one intervening command) ./configure.
“Hang on,” I thought, “those are in the wrong order!
Everyone knows that ./configure comes
first, before make.”

But I was wrong! I hadn’t looked closely enough, and I’m
glad that this year’s exercise made me spot my hasty
misjudgment.

The sequence
“./configure, make, make
install” is correct if the configure
script was generated by Autoconf, because if so, then its
job is to create the Makefile which the
subsequent make command will read. But in
this case, it’s clear that that’s not what this script is
doing. It’s being run with the arguments -o
test.cfg. Autoconf-generated configure scripts
don’t have a -o option at all – so this isn’t
an Autoconf-generated script. It’s some completely
different thing, which shares a name with Autoconf’s
output by pure coincidence.

In fact, it looks to me as if this configure
script is part of the ‘laser controller’ software package
that Flynn was working with. It’s plausible for a software
package that requires a complicated configuration file to
provide a script that generates one automatically, perhaps
intended as a starting point for user editing. Here, we
see Flynn running such a script to generate a starting
file test.cfg, and indeed immediately editing
it with vi to adjust whatever parts of it the
automatic configurer got wrong.

On the other hand, it’s not clear why Flynn did
this, because I highly doubt that the ‘live’ run of the
laser controller at the end of the shell history was using
that configuration file. It’s in the source code
directory, and Flynn called it test.cfg,
which doesn’t sound like a file name or path that the real
software would read by default. After editing it, he
didn’t copy it to any more official location (like
maybe /opt/LLL/etc?), and he didn’t run the
final laser command with any option pointing at it by
pathname.

I think that’s an error: surely, if Flynn went to the
trouble of making and editing a shiny new config file, he
should have finished up by telling the program to actually
use it. On the other hand, maybe this isn’t an error on the
part of the filmmakers; maybe they’re
intentionally depicting a shell history in which Flynn was
a bit distracted, or rushed, and didn’t quite do everything
right! Real users’ shell histories are full of
errors, after all.

Apparently the laser control software needs a lot of free
memory, because in commands 496–500, it looks as if Flynn
is freeing some up. First he checks how much free memory
there is using cat /proc/meminfo (although
see above for another note about that command); apparently
he didn’t like what he saw, because the next thing he does
is to run ps to list the processes, and then
issue a couple of kill commands. Presumably
he got those pids out of the ps listing, and
presumably they corresponded to processes he thought were
likely to be memory hogs. Finally, he
runs ps again, to check the
processes he killed are really gone.

I think if I’d been in his position, my final command
would have been another cat /proc/meminfo,
instead of (or maybe as well as) another ps.
The ultimate aim of this activity isn’t to kill processes;
it’s to free up memory. If the laser program needs memory,
make sure the memory really has been freed up
before you run it!

But, as in a previous section, I think this can
reasonably be imagined as an in-universe mistake – a piece
of carelessness on Flynn’s part, faithfully
depicted by the filmmakers, and not an error on the part
of the filmmakers themselves. He’s certainly nervous, and
quite possibly rushed, or distracted, or excited.

Before he runs the laser program, Flynn
runs touch on a
file /opt/LLL/run/ok. The nominal purpose
of touch is to update a file’s timestamp, but
if you run it on a file that doesn’t exist already, a side
effect is to create that file. Presumably, this
file /opt/LLL/run/ok didn’t exist
already, and Flynn’s purpose here is to create it. Also
presumably, he’s creating it because the laser control
software will refuse to actually control the laser if that
file doesn’t exist. It’s a safety catch, to make it less
likely that the laser is activated by accident.

In addition to this safety catch, there’s a second one:
when Flynn runs the laser controller in his final command,
he also has to give the option -ok
1. This laser program demands two
different ways of saying “yes, I really mean it” before it
will do anything.

Both of these safety-catch techniques are seen in real
Unix software. Git, in particular, uses both, in different
parts of its sprawling feature
set. git-daemon won’t serve a Git repository
over HTTP unless there’s a
file git-daemon-export-ok in the repository
directory; git-clean, which deletes files,
won’t delete them for real unless you give it
the -f option on the command line.

Even with both of these safety catches, I don’t know if
this laser software would meet the requirements of serious
safety standards such as ISO 26262. You can certainly see
things that might still manage to go wrong. Once you’ve
used a command-line “yes I mean it” option, it’s in your
shell history (as we see here!), so that recalling and
re-running the same command doesn’t need repeated
confirmation. And once you’ve made that file in the
program’s run directory, it stays there.

(Or does it? You might imagine that the laser
software deletes /opt/LLL/run/ok, as
a side effect of actually activating the laser. Then
you would need at least one repeated confirmation
– you’d have to re-create the ok file every
time you used the laser. But in fact the next thing Sam
does, after this shot, is to re-run the final command
‘LLLSDLaserControl -ok 1’ to see what it does
– and it turns out that it does still activate
the laser, without him having had to recreate
the ok file.)

But then, we shouldn’t expect this software to be safe by
Serious Business standards. It’s not clear whether Flynn
wrote it himself or got someone else to help, but he did
all of this in secret, so it’s definitely ‘one or two
people coding in a basement’ style software. Nobody is
insisting that it be certified to industry-standard levels
of safety. Flynn is only trying to satisfy
his own standards of caution, which don’t look
all that cautious.

Before firing the laser, Flynn edits a file
called ~/last_will_and_testament.txt. Even if
you knew nothing about the film other than this
screenshot, that would suggest that whatever he’s about to
do with the laser is dangerous to him personally.

In fact (and this is where knowledge of the rest of the
film comes in) he’s going to fire the laser at
himself, disappearing his physical body completely
and digitising it into a piece of sentient computer
software, in the same way that it was done to him in the
original Tron. This time he’s doing it of his
own free will, instead of the hostile Master Control
Program doing it to him nonconsensually, so he has time to
prepare. Probably there’s a risk that the digitisation
fails, leaving him simply dead; and definitely
there’s a risk that he might successfully enter the
software world but find it hard to get out again. (It was
hard to get out in the first film, after all.) Either way,
he’s prudently putting his IRL affairs in order.

But I’m not sure he’s thinking all that clearly. Surely a
will needs to be signed, witnessed, and
left somewhere that people can actually find it
after your death? I certainly wouldn’t want to entrust my
own affairs to the offchance that someone going through my
computer after my death might find a file called ‘will’ in
my home directory. If nothing else, wouldn’t they need my
will to get probate in order to search my home
directory in the first place?

(Also, this isn’t even flynn’s home
directory; it’s root’s home directory, and by
the analysis in a previous section, it seems likely that
that’s /. Not the most obvious place to look
for a will, even after you’ve got access to the
deceased’s machine.)

On the other hand, Sam is quite likely Flynn’s executor,
and as we see here, he has found the will. Even
so, good luck persuading anyone that it’s valid without
signature or witnesses!

(On the other other hand, he only found it by
using the backdoor account, and – again by
analysis in a previous section – it’s possible that Flynn
didn’t know Sam could do that. So it doesn’t seem too
plausible that that was the method by which
Flynn intended Sam to find his will.)

But – yet again – all of this could quite plausibly be
legitimate in-universe mistakes by Flynn himself, and need
not be an error by the filmmakers. I expect if I were
about to perform a life-threatening and untested procedure
on myself and not even tell anyone in advance, I wouldn’t
be thinking all that clearly either!

Everything up to here has been focusing on what
the text says. But there’s one last oddity: how
it says it.

In a typical terminal window, text is in a fixed-width
font. But in the main terminal window in our screenshot
here, the text is in a variable-pitch font. You can see
that most clearly in the lines “Login incorrect” followed
by “login: backdoor”. In a fixed-pitch font, the “ogin” of
“login” would line up vertically between the two lines.
But here, they’re offset from each other, because the
capital and lowercase L are different widths:

Also, the text has been word-wrapped, which isn’t usual.
In normal terminals, if a simple command-line program
writes a line of text straight to stdout
which exceeds the terminal width, the terminal will either
(occasionally) overprint all the excess characters on top
of each other in the right margin, or (more usually) wrap
to the next line at exactly the right margin,
without concern for word boundaries – a long word will be
split across lines wherever it meets the margin, without
even the dignity of a hyphen.

uname -a normally produces all its output on
a single line, so the ‘Unknown.Unknown’ was
probably meant to be on the same line as the rest of it.
(Indeed, we can see another copy of that same text in the
bottom left terminal window, and there it is all
on one line, since that window is wider.) But that final
word has been moved to the next line as a whole,
even though there’s plenty of space left before the right
margin.

I have no idea what’s going on here. What
behaves enough like a Unix terminal program that you can
run a shell session in it, but uses a proportional font
and automatically word-wraps? I suppose it’s possible that
Emacs M-x shell could be reconfigured into
that mode via a lot of work with custom face
configurations and visual-line-mode – but
there’s no emacs status bar here, so it can’t
be exactly that.

Of course, this is an imitation of a Unix system in a
film. So there’s no requirement for it to behave exactly
like real Unix systems. But on the other hand, in a
previous section I spotted at least one clue in this
screenshot that suggests there might have been a
real Unix system involved here, used as the easiest way to
make all these commands deliver the right responses. So
maybe there really is a weird proportional-width
word-wrapping terminal program that I’ve never
encountered?

But if so … it’s not being used consistently
within this screenshot. The top left terminal
window, showing the output of top, is in what
looks like a very similar font, but it is
fixed-pitch. You can see that the four visible characters
of each process name line up in nice columns, whether or
not they’re narrow letters like i
or l – in this window, those letters have
plenty of blank space around them, unlike in the main
window. Compare the ‘in’ of init here with
the ‘in’ of “login” above:

So the three windows aren’t all behaving the same
way as each other!