Where things live, and what a login line says

◈ 10 cards

The standard top-level directories and what each is for, then `/etc/passwd` read field by field — including what happens when the last field is not a shell.

The hierarchy is a convention, and it is worth knowing

Nothing in the kernel requires commands to live in /bin, but every UNIX system puts them there, and a system administrator who cannot say what belongs where cannot repair a machine that will not boot. The layout is organised by two questions: is this needed to start or repair the system? and does it change while the system runs?

/bin and /sbin hold the commands needed to bring the system up or fix it when it is broken — ls, cp, mv, sh, mount. They are deliberately small, and on many systems they are on the root file system so they work before anything else is mounted. Everything else goes in /usr/bin and /usr/sbin. (On Solaris /bin is a symbolic link to /usr/bin and the distinction is cosmetic; on the BSDs they are genuinely different directories. Do not write an answer that assumes either.)
/dev holds device nodes: the character and block special files from lesson 1.
/etc holds system configuration — passwd, group, fstab, the service definitions. Configuration, not programs.
/lib holds the shared libraries that /bin and /sbin need in order to run at all.
/tmp is scratch space, writable by everyone, and purged on a schedule. It may not survive a reboot. Never leave anything there you would miss. (/var/tmp is the variant that does survive reboots.)
/usr is the bulk of the installed system: the rest of the commands, the headers, the manual pages.
/var holds the data that grows while the machine runs: logs, print and mail spools, caches, databases.

`/etc/passwd`: seven fields, colon-separated

The user account database is a plain text file, one line per account, seven fields separated by colons and always in this order:

login_name : password : UID : GID : user_info : home_directory : login_shell

An ordinary user can read it, which is why the second field no longer holds a password. It holds a placeholder — x on Linux, * on some others — and the real hash lives in /etc/shadow on Linux and System V, or /etc/master.passwd on the BSDs, readable only by root. That split is the single most important security change in the file's history: the account data has to be world-readable so that ls -l can turn a UID into a name, but the hashes must not be.

Worked example — one line, seven answers

$ grep "^$(whoami):" /etc/passwd
ada:x:1004:1004:Ada Okafor,,,:/home/ada:/bin/bash

Field by field: the login name is ada; the password field is the placeholder x, so the hash is in /etc/shadow; the UID is 1004 and the GID is 1004 (a private group per user, the Linux default); the comment field is Ada Okafor,,, — the GECOS field, whose commas are sub-fields for office and phone that nothing much uses any more; the home directory is /home/ada, which is what $HOME and ~ are set from at login; and the login shell is /bin/bash.

Both of the last two fields are absolute pathnames, and the seventh has a very specific job: it is the program login executes once authentication succeeds. It is not a name that gets looked up in a table of approved shells at run time — it is a pathname, and login runs it.

What if the last field is not a shell?

This is the question that proves you understand the field, and it is worth doing as a thought experiment before you meet it on an assignment. Suppose the line becomes:

ada:x:1004:1004:Ada Okafor,,,:/home/ada:/usr/bin/date

Authentication succeeds exactly as before — nothing about the password path has changed. Then login execs /usr/bin/date. It runs, prints one line, and exits. When the program login started for you exits, your session is over: the terminal is released and you are logged out. From the outside it looks like a failed login; in fact it was a completely successful login of a session that lasted about a millisecond.

The useful variant of the same mechanism is /usr/sbin/nologin (or /bin/false), which is what system accounts get. nologin prints a polite refusal and exits non-zero; false just exits. Neither is a way of "disabling the password" — the account may authenticate perfectly well — it is a way of making the session end immediately, which is why a service account you cannot log into can still own files and run daemons.

The organising questions are "is this needed to boot or repair the system?" and "does it change while the system runs?" — /bin and /lib answer the first, /var answers the second.

The line read here is ada:x:1004:1004:Ada Okafor,,,:/home/ada:/bin/bash — fields six and seven are both absolute pathnames.