sudoRun a command as root or another user
sudo runs one command as root (or another user) if the sudoers policy allows it, after asking for YOUR password. Every use is logged with your name. It's how admins work on modern servers instead of logging in as root, and sudoers rules can grant exactly one command to a deploy user.
sudo [-u USER] [-i | -s] [-l] [-k] [--] COMMAND [ARGS]You need to restart nginx and read root-only files on devops-lab.
sudoSetuid-root program that checks /etc/sudoers, authenticates you and runs the command.
/usr/bin/sudo is setuid root. It loads the sudoers policy (/etc/sudoers plus @includedir /etc/sudoers.d) and looks for a rule matching who you are, the host, the target user and the exact command path. If allowed and the rule isn't NOPASSWD, it authenticates YOU through PAM (/etc/pam.d/sudo) and records a timestamp in /run/sudo/ts/USER, so for the next 15 minutes on that terminal it won't ask again. It then resets the environment (env_reset; PATH becomes secure_path; SUDO_USER, SUDO_UID and SUDO_COMMAND are set), switches to the target UID and groups, and runs the command, on Ubuntu inside a new pseudo-terminal (use_pty). Each attempt, allowed or denied, is logged to syslog/the journal with the user, terminal, directory, target and full command. Shell features like > redirection are handled by YOUR shell before sudo even starts, which is why sudo echo x > /etc/file fails.
sudo checks the policy, authenticates you (not root), caches that for a while, runs the command as the target user and logs it.
sudo is setuid root, so it starts with root's effective UID while remembering that you (uid 1000) invoked it.
-u USERRun as USER instead of root-iLogin shell as the target (root's env, home, profile)-sShell as the target, keeping your current directory-lList what you're allowed to run-v / -kRefresh / forget the cached authentication-nNon-interactive: fail instead of prompting (scripts, CI)-EKeep your environment (if the policy allows it)-e FILEEdit a file safely as root (same as sudoedit)visudo [-f FILE]Edit sudoers with a syntax check before savingvisudo -cCheck every sudoers file for syntax errorssudo echo 'x' > /etc/fileThe redirect is opened by your unprivileged shell before sudo starts.
echo 'x' | sudo tee /etc/file >/dev/null (tee -a to append)Editing /etc/sudoers with sudo nanoA syntax error can lock everyone out of sudo, and nothing checks it before saving.
sudo visudo, or sudo visudo -f /etc/sudoers.d/name for drop-insdeploy ALL=(ALL) NOPASSWD: /usr/bin/vim, /usr/bin/less, /usr/bin/findEach of these can spawn a shell (:!bash, !bash, -exec), so it's full root without a password.
Allow exact, harmless commands with fixed arguments, or sudoedit for file editsRunning whole scripts with sudo because one line needs rootEvery command in it, including curl | bash or rm, runs as root.
Run the script as a normal user and use sudo only on the lines that need itTry these on a Linux machine of your own. Each task has a hint and a solution.
List what you (devops) are allowed to run with sudo.
Write 'hello' into /etc/lab-motd (root-owned) without opening an editor.
Create a sudoers drop-in that lets devops run only /usr/bin/systemctl status cron without a password, and validate it.
Run 'id' as the www-data user, then show which variables tell a sudo'ed command who started it.
sudoRun a command as root or another user
sudo runs one command as root (or another user) if the sudoers policy allows it, after asking for YOUR password. Every use is logged with your name. It's how admins work on modern servers instead of logging in as root, and sudoers rules can grant exactly one command to a deploy user.
sudo [-u USER] [-i | -s] [-l] [-k] [--] COMMAND [ARGS]You need to restart nginx and read root-only files on devops-lab.
sudoSetuid-root program that checks /etc/sudoers, authenticates you and runs the command.
/usr/bin/sudo is setuid root. It loads the sudoers policy (/etc/sudoers plus @includedir /etc/sudoers.d) and looks for a rule matching who you are, the host, the target user and the exact command path. If allowed and the rule isn't NOPASSWD, it authenticates YOU through PAM (/etc/pam.d/sudo) and records a timestamp in /run/sudo/ts/USER, so for the next 15 minutes on that terminal it won't ask again. It then resets the environment (env_reset; PATH becomes secure_path; SUDO_USER, SUDO_UID and SUDO_COMMAND are set), switches to the target UID and groups, and runs the command, on Ubuntu inside a new pseudo-terminal (use_pty). Each attempt, allowed or denied, is logged to syslog/the journal with the user, terminal, directory, target and full command. Shell features like > redirection are handled by YOUR shell before sudo even starts, which is why sudo echo x > /etc/file fails.
sudo checks the policy, authenticates you (not root), caches that for a while, runs the command as the target user and logs it.
sudo is setuid root, so it starts with root's effective UID while remembering that you (uid 1000) invoked it.
-u USERRun as USER instead of root-iLogin shell as the target (root's env, home, profile)-sShell as the target, keeping your current directory-lList what you're allowed to run-v / -kRefresh / forget the cached authentication-nNon-interactive: fail instead of prompting (scripts, CI)-EKeep your environment (if the policy allows it)-e FILEEdit a file safely as root (same as sudoedit)visudo [-f FILE]Edit sudoers with a syntax check before savingvisudo -cCheck every sudoers file for syntax errorssudo echo 'x' > /etc/fileThe redirect is opened by your unprivileged shell before sudo starts.
echo 'x' | sudo tee /etc/file >/dev/null (tee -a to append)Editing /etc/sudoers with sudo nanoA syntax error can lock everyone out of sudo, and nothing checks it before saving.
sudo visudo, or sudo visudo -f /etc/sudoers.d/name for drop-insdeploy ALL=(ALL) NOPASSWD: /usr/bin/vim, /usr/bin/less, /usr/bin/findEach of these can spawn a shell (:!bash, !bash, -exec), so it's full root without a password.
Allow exact, harmless commands with fixed arguments, or sudoedit for file editsRunning whole scripts with sudo because one line needs rootEvery command in it, including curl | bash or rm, runs as root.
Run the script as a normal user and use sudo only on the lines that need itTry these on a Linux machine of your own. Each task has a hint and a solution.
List what you (devops) are allowed to run with sudo.
Write 'hello' into /etc/lab-motd (root-owned) without opening an editor.
Create a sudoers drop-in that lets devops run only /usr/bin/systemctl status cron without a password, and validate it.
Run 'id' as the www-data user, then show which variables tell a sudo'ed command who started it.