A provider whose image logs you in as "ubuntu" at uid 0 would have walked
straight past the previous check, which compared the string. What makes an
account root is uid 0; "root" is only the usual label for it.
Two places now ask id -u rather than comparing names:
the answer — an account at uid 0 is refused whatever it is called, and says
which case it is rather than a bare "not root"
the invoker — the warning about working as root fires when SUDO_USER is unset
OR when SUDO_USER is itself uid 0. The second is the one that hides: sudo from
a uid-0 account sets SUDO_USER to something that reads like an ordinary user
and is not.
The EUID check that requires the script to run as root was already uid-based and
is unchanged.
Verified by creating a real uid-0 account named ubuntu on this box: refused with
the uid named, where the name check accepted it. That account has been removed —
userdel refused it at first because it matches by uid and saw PID 1 running as
uid 0, so -f was needed, and deliberately not -r, since its home was /root.
Confirmed afterwards that root, /root, root's shadow entry and sudo are all
intact and that root is once again the only uid-0 account.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>