root

The account traditionally named root has UID 0 and broad authority in its security context. Use an unprivileged account for routine work and elevate only for a specific administrative purpose you understand.

Starting a Shell as Another User with su

su, meaning substitute user, starts a shell or command with another account's identity. With no username, the target defaults to root:

$ su

Authentication is controlled by PAM and local policy. A system may ask for the target account's password, restrict who can use su, or keep the root password locked. Do not assume knowledge of a password is the only condition.

Plain su changes identity while preserving more of the current environment. su - USER, also written su --login USER, starts a login-style shell and initializes an environment closer to a fresh login for the target account:

$ su - operator

Exit the subshell when the target-specific work is complete.

Running a Specific Command with sudo

sudo COMMAND requests policy authorization to run one command as a target user, usually root by default. Use -u USER to request another target:

$ sudo -u postgres id

This does not mean the request will be permitted. Sudo policy controls the invoking user, host, target identity, command, and other conditions. Authentication may use the invoking user's password, another mechanism, or no prompt depending on configuration.

Prefer one narrowly scoped administrative command over a long-lived privileged shell when practical. The smaller scope makes accidental commands less likely to run with elevated authority.

Avoiding Persistent Privileged Shells

Commands such as su -, sudo -s, or sudo -i can create a privileged shell when policy permits. Every later command in that shell can have elevated impact until you exit it. Path mistakes, unreviewed scripts, and shell expansions become more dangerous.

Audit behavior is configuration-dependent. sudo commonly records invocations, but a single logged shell launch does not automatically provide a complete record of every command typed inside that shell. Shell history, system audit, and sudo I/O logging are separate mechanisms with their own policies.

Reviewing sudo Authorization

Run sudo -l to list what the current account may request under the active policy:

$ sudo -l

Review command paths, permitted target users, and argument restrictions. A broad-looking rule should not be treated as permission to perform unrelated work.

Editing sudoers Policy Safely

The default sudo policy commonly reads /etc/sudoers and may include files under /etc/sudoers.d/. Other policy sources are possible. Syntax controls much more than a simple list of users and groups.

Use visudo for policy changes because it locks the file and validates syntax before installation:

$ sudo visudo

For a drop-in file, specify its exact path:

$ sudo visudo -f /etc/sudoers.d/application-admins

Do not edit sudoers with an ordinary redirection or unvalidated editor workflow. A syntax or permission mistake can remove administrative access. Keep another verified recovery path available when changing remote authorization.

To practice delegated administration in a controlled environment, try this hands-on lab:

1. Configure User Accounts and Sudo Privileges in Linux - Practice enforcing password policies, locking and unlocking user accounts, securing the root account, and granting administrative permissions, directly relating to the management of superuser access.

Summary

You can now distinguish identity switching from policy-controlled command delegation.

1. Use su - USER only when a target login shell is intended.
2. Request a specific sudo target with -u USER.
3. Minimize time spent in a privileged shell.
4. Review effective sudo rules with sudo -l.
5. Edit sudoers policy only through visudo.