Users and User Management

At the kernel level, Linux users are just numbers (UIDs), but to make working with users easier, we assign usernames to these numbers. Usernames only exist in user-space. Because of this, any program that wants to work with users on a Linux system will need to translate these usernames to UIDs.

/etc/passwd

The plantext /etc/passwd file contains entries for every user on a system. Each line represents a user and has 7 fields seperated by colons:

1. the username
2. the encrypted password for the user (this is no longer used, replaced by /etc/shadow). An x in this field indicates that the password is stored in /etc/shadow. An asterisk * indicates that the user cannot login. If the password field is blank (i.e. you see double colons ::), no password is required to login to this account.
3. The user Id
4. The group Id for the user (this field should correspond to one of the numbered entries in the /etc/group file)
5. The user’s real name (aka the GECOS field)
6. The user’s home directory
7. The user’s login shell

/etc/shadow

Contains encrypted passwords for user accounts

Special User’s

You’ll find a few special users on a Linux system:

1. root - always has UID 0 and GID 0
2. daemon - never has login privileges
3. nobody - an underprivileged user. Some processes run as nobody because they cannot write to anything on the system

Changing a password

Becuase /etc/passwd is just a text file, you can technically modify it directly to change a user’s password. However, you shouldn’t do this. Instead, you can use the passwd command to change a password for a user. If for some reason you cannot use passwd, you should opt to use vipw. This command will prevent race conditions when modifying the /etc/passwd file. It also creates a backup of the file.

SUID

When you temporarily switch to another user, all you are really doing is changing your user Id. There are two ways to do this, and the kernel handles both. The first way to with a setuid executable (sudo) and the second way is with a setuid system call. The kernel has basic rules about what a process can or can’t do, but here are the three essentials that cover setuid executables and system calls:

1. A process can run a setuid executable as long as it has adequate file permissions
2. A process running as root (user ID 0) can use setuid() system calls to become any other user
3. A process not running as root has severe restrictions on how it may use setuid() system calls. In most cases, it cannot.

Because of these rules, you often need a combination of setuid executables and system calls to run a process as another user. For example, sudo has setuid root and once running, it may use setuid() syscalls to become another user.

Effictive UID (euid), Real UID (ruid), and Saved UID (saved UID)

Every process has more than one user Id. The effective user Id is the one you are likely familiar with. This is the user Id that the process is currently running as. However, the process also has a real user Id, which indicates who started the process. Normally, these two values are the same. However, when you execute a setuid program, Linux sets the euid (effective UID) to the ID of the running user, but keeps the original user Id in the ruid (real user Id). Processes also have a saved UID, but we will not need to work with this often.

As stated above, most processes have the same EUID and RUID. As a result, the default output for the `ps` command and other system diagnostic programs only show the EUID. To view both the EUID and RUID, you can run:

ps -eo pid,euser,ruser,comm