Difference between macOS login root and Darwin Terminal root

The recent major security flaw in macOS 11.13.[1,2] has turned the usual advice of not enabling the root account on its head. But it has left me a bit confused about exactly what root account is being discussed.

The Darwin shell has a root account listed, and has many files and directories listed as owned by root, but macOS has no login account enabled for root.

What's the difference between the root account listed as an existing owner for files in the Terminal, and the (disabled) root login account?

The root user (UID 0) exists in every Unix or Unix-like operating system. Every process of a Unix operating systems must run as a valid user/UID, independently of system processes, daemons, services or user-initiated applications. Every basic system-process runs under UID 0 (root), and every system-relevant file is owned by that user. For reasons of security, some processes are running as different "users" with lesser privileges than the superuser root. Such users are there for the solely purpose to start services, such as a webserver, a database, the window server and so on. This means, not every user configured on Unix (or macOS) is a "real" user. In fact, most of those system-users can not log-in interactively.

For example a webserver (nginx, apache, ...) will be started by a script running under UID 0 (=root). The webserver-process afterwards drops the privileges to a specific UID (in this case, it could be the user www). www is not a real user and cannot be used to log in to the system interactively.
There are two ways to "deactivate" a (system) user:

• set the user shell to /bin/false (or any non valid-shell)
• disable the users's password, setting it to an invalid, empty or specific value.

On macOS AFAIK a non-valid user has an empty password and a specific property set on the local OpenDirectory server.

Usually, for a request like "is this a valid user" the OpenDirectory service in macOS does a simple check on the requested user and returns true (user can log in) or false (user cannot log in).
It seems, Apples bug was not to check user's validity but to set it to enabled. On already enabled accounts this had no effect, but disabled accounts became valid, enabled accounts. And since a disabled user has no password, an empty password was accepted as a valid option to log in as superuser/root.

File ownership does not require that a user can login. Files that run the operating system are typically owned by root and are placed by an installation process that requires some form of authentication. Also, the operating system uses other users that run processes beside root. These user usually have their shell set to /bin/false ,cannot login, and may produce files owned by themselves.

To list users on your system and their shell:

dscl . list /Users UserShell

To find files on your system not owned by root or you:

sudo find -x / ! \( -user root -o -user "$(id -un)" \) -exec ls -ld {} +