Sudo and Privilege

Running everything as root all the time removes the one thing that normally limits the damage of a mistake or a compromised program: your own account's restricted permissions. sudo exists so that elevated access is deliberate, per-command, and logged, rather than the default state of every session.

sudo vs. su

sudo command          # run one command as root, using YOUR password
su -                    # start a full login shell as root, using ROOT's password

sudo requires the user's own password (proving it's really them, not that they know a shared root secret) and typically caches that authentication for a few minutes, so repeated sudo commands don't re-prompt every time. su - requires knowing the root password directly and drops you into a persistent root shell - much easier to forget you're in and run something unintended. Many distributions (Ubuntu by default) disable the root password entirely, making su - impossible and sudo the only path to elevated access at all.

Who's allowed: /etc/sudoers

Never edit this file directly with a normal editor - a syntax error can leave the entire system unable to use sudo at all, including to fix the error. Always use visudo, which validates syntax before saving:

sudo visudo

A typical line:

alice   ALL=(ALL:ALL) ALL

Read as: alice, from ALL hosts, may run as ALL users and ALL groups, ALL commands. In practice, most systems grant this via group membership instead of naming individual users:

%sudo   ALL=(ALL:ALL) ALL

Which is why adding a user to the sudo group (Debian/Ubuntu) or wheel group (Fedora/RHEL/Arch) is normally sufficient - see Users and Groups for usermod -aG.

Limiting scope instead of granting everything

sudoers supports much narrower grants than blanket root access - useful for a service account that needs to restart exactly one thing:

deploy  ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart myapp

NOPASSWD skips the password prompt for that specific command only - use it deliberately and narrowly (automation scripts, CI runners), not as a general convenience, since it removes the one check that limits what a compromised session running as that user could do.

What sudo does to the environment

By default, sudo resets most environment variables rather than passing your shell's environment through to the elevated command (env_reset in sudoers, the default on most distros) - see Environment Variables for why this matters: a script relying on $PATH or a custom variable being set may behave differently, or fail, under sudo versus run directly.

sudo -i          # full login shell as root, root's own environment
sudo -s          # a shell as root, keeping more of your environment
sudo -E command  # preserve your current environment for this one command

Every sudo invocation is logged

sudo records what was run, by whom, and when - to /var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL/Fedora, or via journald on systemd systems:

sudo journalctl -u sudo
grep sudo /var/log/auth.log

See Logs and journald for reading these logs in more depth, and Hardening Basics for how sudo's access model fits into a broader security baseline.