~A Gullible's Travels~

Part Two in which Micro Luser Gullible enters his new home.

Get It Try It

II. There's No Place Like Home

'Unix is basically a simple operating system. But you have to be a genius to understand the simplicity.'
 - Dennis Ritchie

IBM PCs had no security. Unless you stood outside your computer room with a shotgun and prevented anyone from entering. IBM PCs had no security because they had no accounts.

Real operating systems must have accounts: you have to 'be' somebody to gain access to the system (to login). On IBM PCs you could get at anything on disk, wipe out all your system files and no one would stop you. IBM's own PC-DOS made it a bit more difficult to shoot yourself in the foot but if you were damned determined you could still trash everything.

You can't do that on Unix. You can't get into a Unix system without being recognised as a valid user. This means someone with a lot more clout than you has to grant you access. You get an account. You will also be required to create a password to identify you when you want to login.

This is an excerpt from an early Unix user account file. It's called 'passwd' and it's found at /etc. It's not used for normal multiuser boots today for several reasons but it still exists and it gives you and idea of what a Unix setup is like.

root:*:0:0:System Administrator:/var/root:/bin/sh
daemon:*:1:1:System Services:/var/root:/usr/bin/false
_www:*:70:70:World Wide Web Server:/Library/WebServer:/usr/bin/false
_sandbox:*:60:60:Seatbelt:/var/empty:/usr/bin/false
_xgridcontroller:*:85:85:Xgrid Controller:/var/xgrid/controller:/usr/bin/false
_xgridagent:*:86:86:Xgrid Agent:/var/xgrid/agent:/usr/bin/false
_appowner:*:87:87:Application Owner:/var/empty:/usr/bin/false
_appserver:*:79:79:Application Server:/var/empty:/usr/bin/false
_windowserver:*:88:88:WindowServer:/var/empty:/usr/bin/false
_spotlight:*:89:89:Spotlight:/var/empty:/usr/bin/false
_tokend:*:91:91:Token Daemon:/var/empty:/usr/bin/false
_securityagent:*:92:92:SecurityAgent:/var/empty:/usr/bin/false
_calendar:*:93:93:Calendar:/var/empty:/usr/bin/false
_cvs:*:72:72:CVS Server:/var/empty:/usr/bin/false
_svn:*:73:73:SVN Server:/var/empty:/usr/bin/false
_mysql:*:74:74:MySQL Server:/var/empty:/usr/bin/false
_sshd:*:75:75:sshd Privilege separation:/var/empty:/usr/bin/false

Each line is a user account record. The records have seven fields separated by colons.

username
password
user ID
group ID
user information ('GECOS field')
login directory
login shell

When you login to Unix the system places you - sets your current working directory - at a specific location: your login directory. You can make all the files you want in that directory, you can stop anyone else from coming into that directory, but you might not be able to get out of that directory. That's up to the system administrator.

Most trusted users are allowed to go anywhere they want because the system is intrinsically secure but guest accounts can run what is known as a restricted shell. With such a shell you are severely limited in what you can do. The administrator can reset your 'root directory' to other than the file system's real root. For example to your own login directory instead. So you just can't get out.

What's a shell? It's a command interpreter, a term particularly appropriate as everything in Unix is like layers of an onion around a system core. The shell is your interface with the operating system. You're able to issue commands through the shell and the shell will call the appropriate modules in the system to carry out your commands.

Unix shells do one thing and one thing only and they do it well: they interpret commands. Things have never been this simple (or as elegant) on PCs. The original PC command interpreter COMMAND.COM did things like set the time and date and list directories. It mixed things up and consequently never got good at the one thing it was expected to do. The new Windows shells - which now include CMD.EXE - aren't really much better. Unix shells are rocket science programs that almost represent complete operating environments with sophisticated control flow and more.

And you get your choice of shells from a wide variety available.

• bash - Bourne again shell. It's a pun. Don't worry about it yet.
• csh - the 'C' shell built by the Berkeley team in the early 1970s after Ken Thompson paid them a visit.
• ksh - Korn shell developed at Bell Labs in the early 1980s by David Korn.
• sh - the original written by Steve Bourne of Bell Labs. The standard on which all the others are based.
• tcsh - the 'TENEX' C shell. Originally written by Ken Greer of Carnegie Mellon in the late 1970s.
• zsh - the Z shell originally written by Paul Falstad in 1990 at Princeton. The name comes from the Unix login username of a colleague of Falstad's ('zsh' for Zhong Shao).

The final field of the user account record specifies the full path to the shell that starts once you're logged in. Most of the real shells are found at the path /bin; one shell is not: /usr/bin/false. This is an actual program that does one thing: it exits immediately with an error code. People trying to login to accounts with this shell will actually succeed in logging in - but they'll be logged right back out again.

The Unix shell plays a pivotal role in the order of things on Unix. Let's look a bit at what happens at a typical Unix terminal of old.

1. User confronts Unix terminal, sits down to work. There's already a program running and its name is login and it's found at /usr/bin.
2. User sees a single cryptic line on screen. This is provided by the program login.

   login:

3. User types username. Name echoes back to the screen.
4. User is now prompted for a password. This does not echo back.

   Password:

Note: the program login doesn't let on if the username is correct or not. You can try this yourself. Open a terminal (console) and type 'login'.

$ login
login: One_Very_Long_Ridiculous_Name
Password:
Login incorrect

The system doesn't tell you 'One_Very_Long_Ridiculous_Name' is one very long ridiculous name (and therefore incorrect). It will wait to see what password you type in. All you'll be told is if the login taken as a whole is correct or not. No information is revealed unnecessarily.

But if you do succeed in logging in you'll get a shell prompt again - there's now a Unix shell running for you, waiting for your commands.

What's happened is the login process has started this shell. The login process has not exited - it's just holding its own, waiting for your shell to exit. If you send your shell the old 'end of file' character (control-D) or type 'exit' then with a real Unix terminal you'd be back at the login process again.

login:

Here's what the login program does.

1. Clears the screen, prints 'login: ', and waits.
2. User types in something at the prompt.
3. Program keeps that 'something' handy, prints 'Password: ' and waits again.
4. User types in a password.
5. Program now checks to see if the username and password match a valid account.
6. If the program can authenticate the user it starts the designated shell for the user and sits and waits for the shell program to exit. The system wakes up the login process when this happens.
7. The program loops back to #1) again.

Unix processes traditionally can't communicate with one another but they can sit and wait for processes they create (child processes) to exit. Whereupon they get woken up again and can continue running. And so forth.

Running a graphical user interface makes things a bit more complex but the idea is the same: you're still running some sort of shell, although it won't be one of the aforementioned Unix command line interpreter shells. You can instead access these shells by other means.

And where you're allowed to roam depends on how your account is set up.

Read on.