Executive summary: "root" is the actual name of the administrator account. "sudo" is a command which allows ordinary users to perform administrative tasks. "Sudo" is not a user.
"root" (aka "superuser") is the name of the system administrator account. The origins of the name are a little archaic, but that doesn't matter.
Root user has user id 0 and nominally has unlimited privileges. Root can access any file, run any program, execute any system call, and modify any setting. (But see below¹).
Prior to the invention of the "sudo" command, if you wanted to perform administrative tasks, you had to login as root, either by getting a login prompt² somehow, or with the
su command ("su" being short for substitute user.)³
That's a bit of a hassle, and also doesn't let you give users partial administrative powers. So the "sudo" command (short for "substitute user do") was invented.
The "sudo" command lets you execute commands with superuser privileges as long as your user id is in the sudoers file, giving you the necessary authorization.
sudo vi /etc/hosts would allow you to edit the hosts file as if you were running as root. You don't even need the root password, just your own login password.
And of course,
sudo su would allow you to simply become root. The result is the same as if you had logged in as root or executed the
su command, except that you don't need to know the root password but you do need to be in the sudoers file.
The sudoers file determines who can use the sudo command and what they can do with it.
The sudoers file is what gives you multiple administrators⁴. Effectively, your administrators are root, plus everybody listed in the sudoers file. Without the sudoers file, the only administrator is root.
In fact, in organizations where someone else administers your computer for you, it's quite common to not know the root password of your own computer — as long as you're in the sudoers file, it doesn't matter.
At one company I worked for, with a ginormous server farm, only a very, very small number of people knew the root passwords. Instead, there was a database of who was allowed to work on which servers. An automated process would add you to the sudoers files of those servers you were authorized to access, and remove you when your authorization expired.
¹ One more thing: modern Unix versions can now restrict even what the root user can do.
Under SELinux (Security Enhanced Linux), there's effectively an access control list that determines which program can do what, and even root can't get past those restrictions.
Under Apple's System Integrity Protection (SIP) (aka "rootless") system, certain files and directories are locked down so that only applications on the appropriate whitelist can access them.
These systems exist to protect a system from the case where a malicious user manages to obtain root access. (Or in some cases, to prevent users from jailbreaking their embedded devices.) For obvious reasons, it's extremely difficult to bypass these restrictions, even with root access.
² The "login: " prompt is another archaic piece of Unix history, dating back to when we all used ascii terminals on serial lines, instead of window systems. You can still get a "login: " prompt by simply typing
login in any terminal window, or by opening an ssh (or telnet or rsh) connection to your computer from elsewhere. You could log in as another user from there if you wanted. (And if your computer happens to have serial ports, you can still configure it to allow logins on them.)
³ It's also possible for individual programs to be given root access. These programs can do anything a user with root access can do, even when run by an ordinary user. These are typically limited to specific tasks. For example, the crontab program has root privileges so that it can edit the cron tables. Obviously, "sudo" has root privileges so that it can do what it does.
⁴ I'm going to cover one more point which I glossed over previously. I've been using "administrator" and "root" interchangeably, but there are other kinds of administrators. These are often called "role accounts", which is to say that these accounts don't belong to actual humans, but instead exist to perform some specific role on the system. If you take a look at the
/etc/passwd file on your system, you'll find dozens and dozens of such accounts.
For example, if mysql was installed on your system, there would be a "mysql" user, and all of the database files, config files, and so forth would all be owned by that user. Only that user (and root, of course) would have the necessary permissions to access the files and run the mysql server. In a sense, that user would be an administrator account, but only for mysql.
If you needed to perform database administrative tasks, you would either become "mysql" with the
su mysql command, or use
sudo where the sudoers file would give you mysql privileges for those specific commands.