On Linux, is the 'root' account powerful because of its name?

Many candidates answer from habit: "root is the admin account." The interview is checking whether you know what the kernel actually uses to decide who is privileged.

The kernel checks the UID, not the name

The capabilities man page describes the traditional UNIX model: privileged processes are those whose effective user ID is 0 (referred to as superuser or root), and unprivileged processes have a non-zero effective UID. Names like root live in /etc/passwd and are only a label mapped to the number. If you add a second entry with UID 0 — say toor or backup — that account is a full superuser too.

Why defenders care

An attacker who edits /etc/passwd to add a UID 0 account gets root without touching the root password or sudo configuration. Auditing for any UID 0 entry other than root is therefore a basic persistence check, and it appears in hardening and hunting checklists.

Root is no longer all-or-nothing

Starting with Linux 2.2, the privileges traditionally tied to the superuser are divided into distinct units called capabilities, which can be independently enabled and disabled. For example, CAP_DAC_OVERRIDE bypasses file read, write and execute permission checks. A service can be given only the capability it needs instead of running as full root.

Why the distractors fail

• "Because of the name" and "because of /root" are folk explanations: the kernel never consults them.
• "Because of the shell" confuses the login program with the permission model; the shell has no bearing on privilege.

What interviewers want

"Privilege is tied to effective UID 0, not the name," plus the follow-through: audit for extra UID 0 accounts, and prefer capabilities over full root.