Sudo & Root
uid 0, the admin group, and the precedence rules that trip everyone up.
Sudo & Root
On macOS, the root account is disabled by default — there is no password you can type, no login prompt that will accept it. Yet every admin still needs to run the occasional privileged command. The answer is sudo: you authenticate as yourself, and the kernel briefly runs one command with uid 0.
Analogy
Root is like the building superintendent's master key at an apartment complex — it exists, but it's locked in a safe and nobody carries it around on their keychain. When a tenant needs into a locked utility closet, they don't get handed the master. Instead they show their ID at the front desk (the sudo password), the concierge unlocks that one specific door for them, and the door auto-locks behind them five minutes later. The sudoers file is the policy pinned above the desk: "residents of the fifth floor may enter the laundry room, residents of the penthouse may enter the roof." Read the list bottom-up — the last scribbled amendment overrides the earlier rules, which is how somebody ends up with access they didn't realize they had.
The admin group
When you create a macOS user and tick "Allow user to administer this computer," you're adding that user to the admin group. That group — and only that group — matches %admin in /etc/sudoers. Stock macOS ships with exactly one rule that grants elevation:
%admin ALL=(ALL) ALL
Translation: any user in admin, from any host, can run any command as any target user. The catch is the password prompt — they have to prove they're still the person sitting at the keyboard.
sudo vs su
su switches your entire shell to another user; sudo elevates one command. On macOS, su root will never work — root has no password. Use sudo -i instead (login shell as root, root's env) or sudo -s (sub-shell as root, your env). To run a single command as another user, not root, use sudo -u otheruser cmd.
The sudoers file and visudo
/etc/sudoers is the policy. Never edit it with a text editor — a syntax error locks everyone out of sudo, and your only fix is Recovery Mode. Always use sudo visudo, which parses the file before writing and refuses to save broken syntax.
Drop-in files in /etc/sudoers.d/ are safer: they're loaded alphabetically and you can remove a single file if something breaks. A typical entry:
# /etc/sudoers.d/10-deploy
%deploy ALL=(ALL) NOPASSWD: /usr/local/bin/deploy
Precedence — the trap
When multiple rules match, the last matching rule wins. This is backwards from what most people assume, and it's the single most common cause of "why is my NOPASSWD not working?" A rule granting NOPASSWD earlier in the file is overridden by any later rule that names the same user and command.
Always read /etc/sudoers and every file in sudoers.d/ top-to-bottom when debugging.
Touch ID for sudo
Recent macOS lets you authenticate sudo with your fingerprint. Add to /etc/pam.d/sudo_local:
auth sufficient pam_tid.so
(Don't edit /etc/pam.d/sudo directly — system updates rewrite it. sudo_local was added for this purpose and persists through updates.)
The timestamp cache
After your first successful sudo in a terminal session, the kernel caches "this user authenticated recently" for 5 minutes. Subsequent sudo calls within that window don't prompt. Useful, but surprising — if your deploy script fails after the first step, a second run might succeed with no visible auth because the cache is still warm.
sudo -vrefreshes the cache without running anythingsudo -kclears it immediately (use this at the end of sensitive scripts)
System Integrity Protection
Even root can't touch everything on modern macOS. SIP protects /System, /usr (except /usr/local), and certain kernel extension paths. You can disable SIP from Recovery Mode's Terminal with csrutil disable, but if you're asking "how do I turn SIP off to install this thing," the answer is almost always: don't, the thing is wrong.
Why this matters
A production macOS build server, a developer's daily driver, and a CI runner all share the same sudoers model. Getting the precedence wrong leaves you with either an account that has more power than you think (NOPASSWD rules no one remembers adding) or an account that has less (an override quietly demands a password you can't provide in a non-interactive context). Read every rule, read them top-to-bottom, and remember the last match wins.