Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

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.)

share|improve this answer
    
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? –  Mehrdad Jul 27 '11 at 15:38
    
After I posted my answer, I realized I hadn't addressed that, so I expanded my answer a bit. :-) –  Steven Pritchard Jul 27 '11 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? –  Mehrdad Jul 27 '11 at 15:58
3  
Nothing like that, thank heavens. :-) –  Steven Pritchard Jul 27 '11 at 16:03
    
lol, thanks. :) –  Mehrdad Jul 27 '11 at 16:36

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.

share|improve this answer
1  
"You can have multiple accounts that all have uid 0." --> WHOA, how?? –  Mehrdad Jul 27 '11 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 '11 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? –  Mehrdad Jul 27 '11 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.). –  Steven Pritchard Jul 27 '11 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. –  Arrowmaster Jul 27 '11 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.