Privilege elevation compared: sudo, doas, UAC, runas and AIX RBAC — and how to detect it

What it is

System	Elevation mechanism	Detecting elevation from a script
Linux (most distributions)	sudo reads /etc/sudoers (and /etc/sudoers.d/*) to decide who may run what as whom	[ "$(id -u)" -eq 0 ] for root; for sudo-capable-but-not-root, sudo -n true succeeds only if sudo needs no password right now (a NOPASSWD rule or a cached credential) and fails instead of prompting
Linux/BSD minimal systems	doas reads /etc/doas.conf, a smaller alternative to sudo	same id -u check; doas -n true fails instead of prompting unless the matching rule has nopass, and doas -C /etc/doas.conf COMMAND prints permit, permit nopass or deny without running anything
Windows	User Account Control (UAC), by default, requires a consent or credential prompt to run a process with the administrator token, even for a user in the Administrators group; Start-Process pwsh -Verb RunAs requests it	#Requires -RunAsAdministrator at the top of a script aborts if not elevated; programmatically, ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
macOS	membership in the admin group grants sudo rights via the default /etc/sudoers; there is no separate UAC-style prompt for command-line sudo	id -u for root; dseditgroup -o checkmember -m "$(whoami)" admin to check admin-group membership without invoking sudo
AIX	root via su; sudo only if installed from the AIX Toolbox; plus Role Based Access Control (RBAC), which can grant specific privileged commands to non-root users	id -u for root; for RBAC, lsuser -a roles NAME shows assigned roles and rolelist -e the roles active in the current session (activated with swrole) — not a POSIX-portable check

Why it matters

"Running as root" and "able to become root" are different states. A script that only checks id -u -eq 0 will treat a sudo-capable non-root user as unprivileged even though the very next command could succeed via sudo. Conversely, a Windows script invoked from a non-elevated shell fails outright on an admin-only operation even though the logged-in user is a full administrator, because UAC's split token means membership in Administrators does not imply the current process holds the elevated token.

How to apply

• Decide up front whether "currently running with root/administrator rights" or "capable of obtaining them" is the actual precondition, and check that specific thing.
• On Windows, put #Requires -RunAsAdministrator at the top of any script that needs elevation, so it fails fast with a clear message instead of partway through with an access-denied error.
• On Linux/macOS, test with sudo -n true before an unattended privileged action; a script that hits a password prompt in a non-interactive session hangs.
• Record which mechanism a host uses (sudo, doas, AIX RBAC) in its inventory; a generic script needs a per-OS branch.

Pitfalls

• Assuming sudo exists; minimal container base images and some BSD installs ship doas or neither by default.
• Treating UAC as a security boundary that stops malicious code from ever reaching an elevated process; Microsoft documents it as a convenience/consent mechanism, not an isolation boundary.
• Checking AIX privileges with a plain id -u when the actual grant was made through RBAC to a non-root user for a specific command only.