On Linux, what is the practical difference between `su`, `su -`, `sudo -i` and `sudo -s` — which password does each ask for, and what environment does the resulting shell get?
answer
- whose password, and whose environment
- dash means fresh login shell
- policy file versus shared secret
- env_reset and a pinned PATH
- redirection happens in your shell first
basics
~20 ssu authenticates you as the target user with that user's password; sudo authenticates you as yourself against a policy. The dash forms (su -, sudo -i) start a clean login shell in the target's home; su and sudo -s keep your current directory and much of your environment.
solid answer
~50 sTwo axes: whose password, and what environment. `su` asks for the **target** account's password — so everyone who needs root must know the root password, and the log shows only that someone became root. `sudo` asks for **your own** password and checks a central policy in `/etc/sudoers`, so root can keep no usable password at all and every command is logged with the invoking user, tty and working directory. On the environment axis, `su -` and `sudo -i` simulate a fresh login: the environment is cleared, `HOME`, `SHELL` and `PATH` are set for the target, the shell reads the target's login files and starts in the target's home directory. Plain `su` keeps your environment and current directory, and `sudo -s` runs a non-login shell after sudoers' `env_reset` has stripped the environment down to a safe set with `secure_path` applied. Most "it works as root but not under sudo" puzzles are a `PATH` or `HOME` difference, not a permissions problem.
code
bash · 14 lines# asks for root's password; keeps your cwd and much of your environment
su
# asks for root's password; full login shell, cwd becomes /root
su -
# asks for YOUR password; login shell for the target user
sudo -i
# asks for YOUR password; non-login shell, cwd unchanged
sudo -s
# compare what the elevated command actually sees
sudo env | grep -E '^(PATH|HOME|USER)='go deeper
Know that su wants the target account's password while sudo wants yours, and that the dash forms drop you into the target's home with a fresh environment.
Explain login versus non-login shells concretely — which variables are set, which startup files are read — and connect env_reset/secure_path to the PATH surprises people hit under sudo.
Show why sudo is the accountable path: per-command logging with the real user, no shared root password, and awareness that granting an interactive shell ends the useful audit trail.
Decide the fleet posture — root password disabled, group-based sudo grants, a documented console recovery route — and be able to justify it against the day the directory service is unreachable.
## Two different doors Both are set-user-ID helpers that let one identity run code as another, but they answer different questions. **`su` (substitute user)** proves you know the *target account's* password. Authorisation is the password itself: anyone who has it can become that user. On a team, root's password becomes shared knowledge, rotating it means telling everybody, and the audit trail records only "a session became root at 14:02". **`sudo`** proves you are *yourself*, then consults `/etc/sudoers` for whether this user, on this host, may run this command as that target. Root can be left with no valid password at all. Every invocation is logged to syslog/journal with the real user, the tty, the working directory, the target user and the exact argv. That accountability, not convenience, is why `sudo` won. The usual defaults: `sudo` asks for the invoking user's password and caches the answer per-tty for a few minutes (`timestamp_timeout`). Sudoers can flip this with `rootpw` or `targetpw`, so never assert "sudo always asks for your own password" without saying "by default". ## The login-shell axis Orthogonal to authentication is what the resulting shell looks like. A **login shell** is one started as if you had just logged in: environment built from scratch, working directory set to the target's home, and the target's login files (`/etc/profile`, then the user's profile) sourced. A **non-login** shell inherits the environment it was invoked from. - **`su`** — no login shell. You stay in your current directory and keep most of your environment. util-linux's `su` sets `HOME` and `SHELL` (and `USER`/`LOGNAME` when the target is not root) and resets `PATH` for non-login shells, but the rest of your variables come along. This is how you end up as root with your own `PATH` and, more insidiously, root-owned files appearing under your own `HOME` because a tool wrote to `$HOME/.cache`. - **`su -`** (`su --login`, or `su - alice`) — full login shell. Environment cleared, `HOME`/`SHELL`/`USER`/`LOGNAME`/`PATH` set for the target, `cd` to the target's home, login files read. - **`sudo -i`** — sudo's equivalent of `su -`: runs the target's shell as a login shell, in the target's home, with an initialised environment. - **`sudo -s`** — runs the target's shell as a **non-login** shell, leaving your working directory alone. - **`sudo <command>`** — no shell at all. This matters: with no shell, your aliases, functions and shell redirections do not apply. `sudo echo x > /root/f` fails because the redirection happens in *your* shell, before sudo runs. ## What sudo does to the environment Modern sudoers ships `Defaults env_reset`: the command's environment is built fresh rather than inherited, with only variables named in `env_keep` carried over (typically `TERM`, `DISPLAY`, `LANG`, proxy variables). `Defaults secure_path="…"` then pins `PATH` to a trusted list. Both exist to stop the caller from steering a privileged program — a writable directory early in `PATH`, or a hostile `LD_PRELOAD`, would otherwise turn any sudo grant into arbitrary root code. The visible consequence: a build that works when you `su -` may fail under `sudo` because a tool in `/opt/…/bin` is no longer on `PATH`, or because `HOME` still points at your own home so a tool reads your config instead of root's. Before blaming permissions, run `sudo env` and compare. ## `sudo su -` and other habits `sudo su -` is common: authenticate as yourself through sudo, then hand off to `su` for a root login shell. It works, but `sudo -i` does the same thing in one process and one log line, and it does not require the sudoers rule to grant a shell. The deeper point is that any rule granting an interactive root shell — through `su`, `-i`, `-s`, or a shell-escapable command — collapses to "full root", so the logged command is the last useful thing the audit trail records. `sudo -u alice -i` gives you a login shell as any target, which is the correct way to reproduce a service account's environment. Do not test service behaviour from a root shell and assume it matches. ## Choosing On a multi-admin machine: disable password login for root, grant through sudoers by group, and use `sudo -i` when you genuinely need an interactive root session — accepting that the audit value of everything after that line is limited. Keep `su` for switching into a *service* account from root, where there is no password to know.
- Why does `sudo echo hello > /root/notes` fail with permission denied even though the sudo rule allows it?Because the redirection is performed by *your* shell, as you, before sudo ever runs — sudo only elevates `echo`. The fix is to elevate something that does the writing: `echo hello | sudo tee -a /root/notes`, or `sudo sh -c 'echo hello > /root/notes'` if the rule permits a shell. Be aware that granting `tee` or a shell in sudoers is effectively granting root.
- What are `env_reset` and `secure_path` in sudoers protecting against?Caller-controlled environment steering. Without them, an unprivileged user could put a malicious binary early in `PATH`, or set variables the privileged program trusts, and have the elevated command execute their code. `env_reset` rebuilds the environment from a small allowed set and `secure_path` pins `PATH` to trusted directories, so what runs under sudo is what the policy author intended.
- Your team wants root's password disabled entirely. What breaks, and how do you still recover a host?`su` to root stops working, and so does anything that authenticates against root's password. Recovery moves to console access: the bootloader's rescue path or single-user mode, or the hypervisor/BMC console. Plan it explicitly — decide who can reach the console, protect the bootloader, and confirm that at least one sudo-capable group survives a broken directory service.
saying these in an interview costs you the question
- Saying sudo always asks for the root password
- Believing `su` and `su -` differ only in typing
- Blaming permissions when the real difference is PATH
- Thinking `sudo cmd > file` writes the file as root
- Treating `sudo su -` as more secure than `sudo -i`