su vs sudo: Linux Privilege Escalation Explained

You just logged into a Linux server to check the Nginx configuration. A colleague tells you to run sudo nginx -t, while another tutorial says to type su - first. Both give you root privileges, but whose password you enter, which directory you land in, and what identity runs the next command are all different.

su drops you into the target user's shell

Suppose the server has a deployment account named deploy. Running su - deploy and authenticating successfully starts a login shell for that user. At that point id -un shows deploy, and subsequent commands run with its permissions. Typing exit returns you to your own shell. Omitting the username makes su default to root.

su - deploy
id -un
exit

When a regular user uses su, they typically enter the target account's password . su - deploy usually verifies deploy 's password, while su - verifies root's password. Switching from root to another account often requires no password. Exactly who may switch and how authentication works is determined by the system's PAM configuration. Even with a correct password, account status or local access restrictions can still cause the switch to fail.

sudo runs a specific command with authorization

First run sudo id -un. Under typical configuration, if you have permission, it executes id as root and outputs root. Immediately running id -un again shows your own username. To run as a specific user, add -u deploy; the system checks whether you are authorized for that user.

sudo id -un
id -un
sudo -u deploy id -un

In common sudoers policies, when a password is required it defaults to the caller's own password . To see which commands you are allowed to run, use sudo -l. If NOPASSWD is configured, or a previous authentication cache is still valid, the command may run without prompting. sudo -k invalidates the current authentication cache. Administrators can also change which account's password is verified via policy.

Password verification and command authorization are separate. For example, a shared server might allow only the on‑duty account to run Nginx configuration checks as root. That account enters its own password but is still limited to the approved commands. Typical authorization rules live in /etc/sudoers or included files, and administrators usually edit them with visudo to validate syntax.

Both approaches grant root privileges, but the scope of privilege differs.

What does the dash in su vs su - do?

Plain su usually keeps the current working directory and may inherit some environment variables. The dashed form su - is equivalent to su --login; it starts a login shell, changes to the target user's home directory, and initializes the environment as if that user had logged in.

Starting from /home/alex/app and switching to root. id -un shows the effective identity, pwd shows the current directory. Both switches make id -un output root. But if you then run ls ./config, you will look in different directories. The $ and # prompts are common but customizable; to confirm identity, check id -un output.

Plain sudo command typically starts from the original working directory, though the environment passed to the command is still governed by policy. If after switching you cannot find a command or read the expected configuration, run echo "$HOME" and echo "$PATH" to verify the home directory variable and command search path.

A common pitfall: running sudo echo "$HOME" expands $HOME in your current shell before sudo runs, so it prints your own home directory. To compare the actual environment passed to the command, run printenv HOME and sudo printenv HOME separately.

Why does su - often fail on Ubuntu?

Ubuntu locks the root password by default. When a regular user runs su -, they often see Authentication failure. If that same user has sudo authorization, they can authenticate with their own password. To enter a root login shell via sudo, run sudo -i and then exit. Single commands and login shells can be authorized independently. If you can run a sudo command but sudo -i is denied, check your permissions with sudo -l. sudo -u deploy -i opens a login shell for deploy when authorized. su also has a single‑command mode: su -c 'id -un' deploy authenticates and then runs the command as deploy before returning.

Why does adding sudo still give "permission denied"?

Assume a config file is writable only by root. In the first line below, the redirection > is processed by your current shell, which tries to open the target file. As a regular user you lack write permission, so it fails with Permission denied. The second line pipes the output to tee running as root, which performs the write.

sudo printf '%s
' '# demo' > /etc/su-sudo-demo.conf
printf '%s
' '# demo' | sudo tee /etc/su-sudo-demo.conf >/dev/null

tee

overwrites the target file by default; use tee -a to append. Another common mistake is sudo cd /root. cd is a shell builtin; an external command cannot change the current shell's directory. If you only need to list /root, sudo ls /root suffices.

Choosing the right tool for daily server management

Task → Command

Check Nginx config as root → sudo nginx -t List a directory as the deploy user → sudo -u deploy ls /srv/app Verify deploy user's password and enter its login shell → su - deploy Enter a root login shell via sudo authorization → sudo -i If you encounter "deployment script cannot write to directory", run sudo -u deploy test -w /srv/app and immediately check echo $?. A return value of 0 means the write permission check passed. This test uses the deploy account's identity directly, avoiding the need to create a test file.

On a multi‑admin server, using sudo for each command aids auditability. Standard sudo logs record the invoker and the requested command. When you start a shell with sudo -i, the log records that launch; to trace every command typed inside that shell, additional auditing setup is required.