Why you do not log in as root

What root actually is

root is not a very powerful user. root is the user for whom the permission check is skipped. UID 0 is a special case in the kernel: where an ordinary process's request to open, write, unlink or kill is tested against ownership and mode bits, root's request is not tested at all. There is no are you sure, because there is no are you.

That single sentence generates every rule in this lesson.

Worked example: the same command, run twice

You are cleaning up a build directory and you fat-finger the path. As yourself:

$ rm -rf /build
rm: cannot remove '/build': Permission denied

The permission check did its job. / is owned by root and not writable by you, so the kernel refused, and the mistake cost you a line of output.

Now the identical typo from a root shell:

# rm -rf /build
#

No output, no confirmation, no undo. If /build existed, it is gone, along with everything under it, and your only recovery is a backup. rm was not being reckless — it was being obedient. The check that would have caught you was the one root does not get.

Three ways to become somebody else

su with no argument makes you the superuser for an entire shell. It asks for root's password, and every command you type afterwards — including the ones you type ten minutes later when you have forgotten where you are — runs with the check disabled. You leave with exit or Ctrl-D. Plain su gives you root's identity but not a login shell, so you keep your own environment and working directory; su - gives you root's login environment as well.

su bob switches you to another ordinary user and asks for bob's password — which means it is not a mechanism for administration so much as for standing in someone's shoes, and it requires you to know a secret that is not yours.

sudo command runs exactly one command with elevated privilege, prompts for your own password, and consults a policy file before it agrees. The policy lives in /etc/sudoers, whose entries have the shape

who where = (as_whom) what

— a user or group, the host the rule applies on, the identity to run as (root unless stated), and a comma-separated list of full pathnames of permitted commands. Two details matter and are examinable: the file is edited only with visudo, which validates before installing (a syntax error in sudoers locks everyone out of privilege at once), and where several entries match, the last match wins — not the most specific one. sudo -l lists what the current user is permitted to run.

The four reasons, which is what the question is really asking

1. There is no undo, and the blast radius of a typo is the whole machine. A misplaced space or slash is refused for you and executed for root. Backups are the only recovery.
2. Every process you start inherits the privilege. A browser, a downloaded script, a text editor with a plugin — anything you launch from a root shell runs as root. One exploited program and the attacker owns the system rather than one account.
3. There is no per-user audit trail. When four administrators share one root login, the logs record that root removed the file. sudo logs each command against the human who ran it, which is what makes an incident reconstructable.
4. Least privilege is the principle, and sudo is the mechanism that implements it. Hold the smallest privilege that does the job, for the shortest time, over the narrowest scope. sudo grants privilege one command at a time, under a policy someone wrote down, with a record. A root login grants everything, forever, anonymously.

Which of these five operations genuinely needs elevation? Installing a system package; editing a file in your own home directory; changing the system clock; reading your own mail; binding a server to port 80. Answer: the first, the third and the last — and for each of them, one sudo line is enough.