sudo and root
Root (uid 0) bypasses all file permission checks. sudo lets a normal user run a single command as root without becoming root permanently. The footguns: sudoing every command, chmod 777 as a fix, and recursive chown on the wrong path.
You want to install a package and every command fails with Permission denied. Someone tells you: “just put sudo in front.” So you start doing it everywhere. Then one day a typo with sudo rm -rf wipes a directory that would have been safe without it. Root access is not a convenience feature — it is a loaded weapon. This lesson is about handling it deliberately.
After this lesson you can explain what root (uid 0) is and why it bypasses permission checks, use sudo to run a single command with elevated privileges, understand what the sudoers file controls, and identify the three most dangerous sudo/chmod habits to avoid.
Root is the superuser — uid 0 bypasses all permission checks. Linux has one special user identity: root, with user ID 0. The kernel’s permission check — the three-step UID/GID rule from the previous lesson — has a hard-coded exception: if the process’s effective UID is 0, all read and write checks pass automatically. Execute permission is still checked for regular files (root cannot execute a file with no execute bit set for anyone), but for ownership and rwx access root is unrestricted.
This means root can read /etc/shadow (the hashed password file), write to any file regardless of its mode, and chown files away from their owners. Being root is not a permission level — it is a bypass of the permission system entirely.
sudo runs one command as root without logging in as root. Instead of switching to the root account, sudo executes a single command with root’s effective UID, then returns you to your normal user session:
# install a package (requires root)
sudo apt install htop
# edit a root-owned config file
sudo nano /etc/hosts
# see who you are before and after
whoami # alice
sudo whoami # root
whoami # alice ← back to normalsudo prompts for your own password (not root’s), checks the sudoers configuration to confirm you are allowed, runs the command, and logs what was run. That log entry in /var/log/auth.log is what makes sudo auditable in ways that su - or sudo -i are not.
The sudoers file controls who can run what. /etc/sudoers (always edited via visudo, never directly) defines which users or groups can run which commands as which targets:
# syntax: who where=(as_whom) command
alice ALL=(ALL) /usr/bin/apt, /usr/bin/systemctl
%devs ALL=(ALL) NOPASSWD: /usr/bin/dockerOn Ubuntu/Debian, being in the sudo group grants unrestricted access (ALL=(ALL:ALL) ALL). On RHEL/CentOS the equivalent group is wheel. Your cloud VM’s default user (ubuntu, ec2-user, centos) is typically in one of these groups at provisioning time.
Never add NOPASSWD: ALL for a user — it defeats the point of sudo entirely.
Least privilege: use the minimum access that gets the job done. The principle of least privilege applied to root access means:
- Run services as dedicated non-root service users (
www-data,postgres,node). If the process is compromised, the attacker gets that user’s access, not root. - Use
sudofor the specific command that needs it, not for an interactive root shell. - Prefer
sudo systemctl restart nginxoversudo -ifollowed bysystemctl restart nginx. The former is logged; the latter gives you an unrestricted root session where every subsequent command is equally dangerous. - Never run a web server, database, or application runtime as root.
Deploying a config change safely.
You need to update /etc/nginx/sites-available/myapp.conf (owned by root) and reload nginx.
Bad habit — opening a root shell:
sudo -i
nano /etc/nginx/sites-available/myapp.conf
nginx -t
systemctl reload nginx
exitEvery command in that shell runs as root. A typo on any line is a root-level mistake.
Better — targeted sudo:
sudo nano /etc/nginx/sites-available/myapp.conf
sudo nginx -t
sudo systemctl reload nginxSame result. Three logged sudo invocations instead of an unlogged root session. If nginx -t fails you are still in your normal user context — you cannot accidentally wipe something with a misdirected rm.
▸Why this works
On macOS, root exists and sudo works the same way. The default sudoers configuration grants members of the admin group full sudo access (equivalent to the sudo group on Ubuntu). System Integrity Protection (SIP) adds an additional layer that restricts even root from modifying protected paths like /System and /usr — something Linux does not have. On Linux, root truly has no restrictions.
▸Common mistake
Two footguns that beginners reach for together: sudo chmod 777 /var/www/html and sudo chown -R root:root . run in the wrong directory. The first makes every file world-writable — any local user or compromised process can overwrite your application files. The second, if run one directory higher than intended (a tab-completion slip), can change ownership on your entire home directory, locking you out of your own files. The safe alternative: identify exactly which file or directory needs what permission, and set only that. chmod 777 is essentially never the correct production permission.
Why is running your web application as root considered dangerous?
Root (uid 0) is not a high-permission user — it is a bypass of the permission system. The kernel skips rwx checks for uid 0 on reads and writes. sudo runs a single command as root, prompts for your own password, and logs the invocation. The sudoers file (/etc/sudoers, edit via visudo) controls exactly who can run what. Apply least privilege: run services as dedicated non-root users, use targeted sudo <command> instead of sudo -i, and never reach for chmod 777 as a fix — diagnose the actual ownership or permission mismatch instead.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.