Programs that make changes system-wide require sudo unless I am already the root user.

Now, the question is: how exactly does the system figure out that I am (not) root?

Does it:

  • Check to see if I'm in a specific group? If so, which group do I need to be in?

  • Check against a well-known ID of root itself (i.e. "the root user" is hard-coded into the source)?
    If so, what happens if my root account gets corrupted? Would I be forced to reinstall the OS, since there's no way to create another account with root privileges?

  • Check my name/group against some file's contents and granting the right privilege? If so, which file contains this information?

  • Do something else? If so, what does it do?

5 Answers 5


Usernames on Unix aren't significant. Only numeric user IDs are. The numeric ID of root is always 0. That is hard-coded all over the place (in the kernel, in utilities, etc.).

You can find your numeric user ID by running id.

Note that your numeric user ID is a property of the running process. When you login, the process you login through (login, sshd, etc.) is running as root (UID 0), and once your login is authorized, it switches to your user ID and runs your shell (specified in /etc/passwd). From there, to use sudo, su, or something else to switch user IDs, those programs have the setuid bit set (chmod u+s or chmod 4xxx will set that), so that when they execute, the process runs as the owner of the program (root, UID 0). Again, once you're authorized, they run whatever program (whatever you told sudo to run, a shell, etc.) as root. (In the su case, if you specify another user to switch to, it drops to that UID, then runs the shell or whatever.)

To answer your other question, there's really no way for the root account to "get corrupted" since it really is just a number, but there might be reasons why you can't just login as root (like forgetting the password, for example). None of these should require a re-install of the OS, but they might require a bit of technical skill to fix. (For example, if you forget the root password, you can use sudo to get to root by using your password, boot into single-user mode to reset the password, or boot from live media or a rescue environment.)

  • Right, I didn't expect it to actually check the name, haha. But then what about the second part of my question: what if it gets corrupted? Is there no way to make another user have ID 0?
    – user541686
    Jul 27, 2011 at 15:38
  • After I posted my answer, I realized I hadn't addressed that, so I expanded my answer a bit. :-) Jul 27, 2011 at 15:53
  • Ah, thanks! +1 So there's nothing like e.g. the Windows registry that could be "corrupted" on Linux, preventing the account from being used permanently?
    – user541686
    Jul 27, 2011 at 15:58

In 25 years of dealing with Unix, I've never seen a case where the root account was corrupted without the system itself being useable. Forgotten passwords can easily be reset, and I don't see that as corruption. There was one memorable incident on a Vax running BSD where I accidentally (don't ask) removed everything from /dev, including the entries for the tape drive (1/4" reel tapes). This makes it a bit hard to restore from backup.

Under Unix, there really isn't anything to corrupt. The login process just starts up a shell and runs the rc files from root's home directory. With the exception of the rc files, if the rest doesn't work for root, it probably won't work for anyone else. If you are logging in as root to a graphical system (KDE or Gnome), all I can say is "Just don't".

You can have multiple accounts that all have uid 0. This can be used as an alternative to sudo when there are multiple administrators for a machine. The downside is that you now have multiple root accounts to protect. You also don't get the logging that sudo does for you.

  • 1
    "You can have multiple accounts that all have uid 0." --> WHOA, how??
    – user541686
    Jul 27, 2011 at 16:06
  • @Mehrdad - Most systems allow you to specify a uid when adding a new user. Just specify uid 0, and you have another root user.
    – KeithB
    Jul 27, 2011 at 16:14
  • +1 I'm gonna have to try this. Just wondering, though: If it's a user ID, then how is it not really an ID?
    – user541686
    Jul 27, 2011 at 16:15
  • Again, only the numeric IDs are significant. User names are more for our convenience than anything else. They're just mapped to a numeric ID (in /etc/passwd, NIS, LDAP, etc.). Jul 27, 2011 at 16:41
  • An example of how this is useful is that some people like to create a 2nd root account with a different name (toor is common) and exactly like the normal root account except it has a different login shell. This way they have a root account with the login shell they want without changing the root accounts login shell and possible causing issues. Jul 27, 2011 at 17:51

Steven Pritchard's answer is good, but I thought I'd offer a different presentation of similar information.

Each process runs as a certain user¹. The user is identified by a number, the user ID, which is stored in the process information available only to the kernel. The user whose user ID is 0 has special privileges, and is normally called root; the name rootis not special to the kernel (but if you change it you're likely to confuse a lot of applications). Many things, such as loading kernel modules, accessing most hardware devices directly, and so on, require that the process that performs the action be running as user ID 0².

When the system boots, the first process started by the kernel runs as the superuser. That process, called init, eventually starts a number of system services (cron, syslogd, …) and login programs (login, sshd, etc.).

When you log in, you enter credentials (name, password, …) and the login program checks these. If the credentials are accepted, the login program changes to your user ID (that's one of the privileges granted to the superuser).

If you screw up the user database (which is unlikely if you don't go around editing or removing random files as root), you may not be able to log in any more. You'll still be able to boot into single-user mode or from a live CD to repair your system.

The program sudo lets you run commands as root. Normally, if you run a program, it inherits the user ID of the process that started it. But sudo is setuid root: this is an exception, determined by the permission bits on /usr/bin/sudo, that make it run as user ID 0 instead. sudo checks whether the user that invoked it is allowed to run a command with elevated privileges (by consulting /etc/sudoers), and either runs the command or signals an error.

¹ Sometimes more than one, but this won't come up in this answer.
² Or have the right capability, but never mind this for now.


So the previous responses from Steven Pritchard and KeithB are correct, but there are a few subtleties to be aware of on how process id is actually managed.

As mentioned, username is totally irrelevant to the kernel or any process management, and is only mapped in userspace based on the /etc/passwd or similar mechanisms, so forget all about that. Root is indeed hardcoded, and is uid 0 by definition on any POSIX system (or anything even remotely UNIXy, as far as I'm aware).

Permissions are calculated done based on properties of the currently executing process. There is the real uid, which is the uid of the user who started the process, and the effective uid, which is the uid the process is treated as for the purposes of permissions. When you run things from the shell, the shell is the parent process -- and child processes always inherit the real uid of the parent, which is your uid if you're running in a login shell. Processes for which setuid is enabled can change their effective uid (but never their real or saved uid) -- processes running with effective uid of 0 (as root) can change to any other uid, and other processes can only change the euid between the real and saved uid -- another process property that is always the original euid of the process (equivalently, the effective uid of the parent at the point when exec() was called). This can't be changed by unprivileged users, and root may change it only to the real uid.

All of those is also relevant for group permissions, just s/uid/gid.

As an aside, I generally find sudo less helpful than enabling su and properly managing the wheel group.


Concept of "root" privilege is spread into various control mechanism:

  1. Hardware: Intel CPU (and all other CPU generally) have various "privileged state" - and in each of these privileged state you can or cannot run certain class of assembly instruction - generally the more privileged state will have the power to execute more instructions.



And one of the privileged instructions is to control the memory page table. And these various ring also give you kernel vs user-space execution threads.

  1. From (1), through page table mechanism, you will also have various types of memory: ring 0 or ring 3 memory.



Ring 0 will have more privilege, and store all your sensitive information - among them is your USERID information. If you are userid=0, you are privileged, and if not, then just a normal user. And every userid have different page tables in the kernel - which is why each process cannot modify each other memory directly. And remember the userid is stored in ring0 memory - your processes running in ring 3 will never be able to modify this info, and if you can , then you must have managed to escalate into the kernel to modify it ("privilege escalation").

To check whether you are root or non-root - do this in the kernel:

  if (current_cred()->uid != 0)
     return -EPERM;

And if you are not in the kernel - you have no access to all the credentials stored in the kernel. And one process cannot read another process memory - so no such check is needed if you are not in kernel, which can see ALL the memory for all process.

To sum it up: any processes you are running, which is always running at ring 3 privilege (for Intel), will have userid information kept in the kernel - which must have been originally created from another kernel component, or a root process (userid = 0). Any root-owned process (which is still running at ring3) will have capabilities (why? because it is written inside the Linux kernel source code itself:

https://stackoverflow.com/questions/15774548/check-for-user-root-within-linux-kernel) to transition into ring 0 privilege easily. This explained why no matter how you modify your own memory, (which is all running in ring 3) you will never be able to see/change your userid.

And you asked if ownership stored in files - yes files do contain userid ownership. And a running process (with a particular userid) cannot modify another files with a different userid. Security is compartmentalized this way in files + running processes (where userid is stored in kernel memory). But you cannot be fully assured that someone else cannot read your physical files.

If you can take the harddisk to another machine which you have root control, you can assume as ANY userid needed to read that particular userid-owned physical files on the harddisk. ie, if you does not have physical security, you can bypass all security mechanism on the harddisk, unless it is encrypted.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .