Basic Principles of Linux Permission Control

(Click the blue text above to quickly follow us)

This article is recommended by the original author (Lü Kai)

Below are examples of user and group information. The password information in /etc/shadow is stored encrypted and will not be exemplified.

$cat /etc/passwd |head –n5

root:x:0:0:root:/root:/bin/bash

daemon:x:1:1:daemon:/usr/sbin:/bin/sh

bin:x:2:2:bin:/bin:/bin/sh

sys:x:3:3:sys:/dev:/bin/sh

sync:x:4:65534:sync:/bin:/bin/sync

$cat /etc/group |head –n5

root:x:0:

daemon:x:1:

bin:x:2:

sys:x:3:

adm:x:4:miracle

In the output, the first character indicates the file type, where a regular file is (-), a directory is (d), a socket file is (s), a pipe file is (p), a character file is (c), a block file is (b), and a link file is (l); the second character onwards, the -rwxr-xr-x part indicates the file permission bits, which total 9 bits.

For the file /usr/bin/qemu-i386, the meaning of this permission control is:

1. The rwx in positions 2-4 indicates that the file can be accessed by its owner with r, w, or x permissions.

2. The r-x in positions 5-7 indicates that the file can be accessed by users in the same group as the file with r or x permissions.

3. The r-x in positions 8-10 indicates that the file can be accessed by other unknown users with r or x permissions.

For the permissions set on test/, test2/, test3/:

1. The r, w, x permissions for each control group are represented by a single octal digit; for example: 755 represents rwxr-xr-x.

2. The s, t permissions will replace the x position; setting s, t permissions requires adding a digit in front of the corresponding octal permission control group for r, w, x; s permission is for owner and group control, t is for others control.

3. To set owner s, add 4; to set group s, add 2; to set others t permission, add 1; for example, if t is set for test/, it would be 1775, indicating rwxrwxr-t.

Process Permission Control Information

Process Permissions

For processes, the following attributes are related to file access permissions:

• effective user id: the UID related to the process’s file access permissions (abbreviated as euid).

• effective group id: the GID related to the process’s file access permissions (abbreviated as egid).

• real user id: the UID of the user who created the process when logging into the system (abbreviated as ruid).

• real group id: the GID of the user who created the process when logging into the system (abbreviated as rgid).

• saved set user id: copied from euid.

• saved set group id: copied from egid.

Example

We can use ps and top to view processes with euid and ruid. Or use top to view the euid and ruid of processes.

Example of viewing through top:

1. First, enter top to get something like this

Where PID corresponds to the process, USER is the corresponding effective user, RUSER is the corresponding real user.

Process File Access Permission Control Strategy

Rules

General Permission Control Strategy for Process File Access

For process file access, the most important is euid, so its permission attributes are centered around euid.

• The process’s euid is generally defaulted to its ruid value.

• If the executable file’s executable permission bit is s, after the process calls exec, its euid is set to the user id of that executable file.

• The process’s saved set user id is copied from euid.

• When the process’s euid matches the file’s user id, the process has the permissions set by the file’s user permission bits.

• The control rules for group permissions egid are similar.

Modifying Permission Attributes through exec Execution

When calling an executable file through exec:

• The process’s ruid value remains unchanged;

• saved set-user ID always comes from euid;

• euid value depends on whether the file’s set-user-ID bit is set.

As follows:

Example

Here are a few more special examples:

– Set the set-user-id

$ls –l /usr/bin/sudo

–rwsr–xr–x1root root71288 February28 2013 /usr/bin/sudo

As mentioned earlier, the meaning of this output is that for the /usr/bin/sudo file,

• The first three bits rws indicate that the file can be accessed by its owner with r, w, or s permissions.

• The next three bits r-x indicate that the file can be accessed by users in the same group as the file with r or x permissions.

• The last three bits r-x indicate that the file can be accessed by other unknown users with r or x permissions.

After this setting, for the owner, there is no difference in read, write, and execute permissions. However, for ordinary user processes that do not belong to the root group, it is very different.

When an ordinary user process executes the sudo command, it gains execute permission through the x in others, and then through the s in user, the ordinary user process temporarily acquires the permissions of the sudo executable file’s owner (root), i.e., superuser permissions.

This is why ordinary users can execute many administrator-level commands through the sudo command.

– Set the sticky bit

$ls –l / |grep tmp

drwxrwxrwt 25root root12288 July2009:09tmp

After this setting, for the /tmp directory, anyone has read, write, and execute permissions, which is no different. However, the sticky bit t set for others has a different function.

If the directory does not have the sticky bit set, anyone with write permission to the directory can delete any files and subdirectories within it, even if they are not the owner of the corresponding files and do not have read or write permission; after setting the sticky bit, users can only write or delete files and subdirectories that belong to them.

This is why anyone can write files and directories to the /tmp directory, but can only write and delete files or directories they own.

Example of the man program application snippet, describing the use of set-user-id and saved set-user-id

The man program can be used to display online help manuals, and the man program can be installed with a specified set-user-ID or set-group-ID for a specified user or group.

The man program can read or overwrite certain files, which is generally configured by a configuration file (usually /etc/man.config or /etc/manpath.config) or command line options.

The man program may execute some other commands to process files containing the displayed man pages.

To prevent processing errors, man switches between two privileges: the privilege of the user running the man command and the privilege of the owner of the man program.

The main point to grasp: when only executing man, the process privilege is the privilege of the man user; when executing a subprocess through man (such as invoking a shell command through !bash), the user switches to the current user and switches back after execution.

The process is as follows:

1. Assuming the man program file is owned by the user man and has its set-user-ID bit set, when we exec it, we have the following situation:

• real user ID = our user UID

• effective user ID = man user UID

• saved set-user-ID = man user UID

The man program will access the required configuration files and man pages. These files are owned by the man user, but since the effective user ID is man, file access is allowed.

When man runs any command for us, it calls setuid(getuid()) (getuid() returns the real user id). Since we are not a superuser process, this change can only alter the effective user ID. We will have the following situation:

Now when the man process runs, it takes our UID as its effective user ID. This means we can only access files that we have permission for. In other words, it can safely execute any filter on our behalf.

• real user ID = our user UID (will not change)

• effective user ID = our user UID

• saved set-user-ID = man’s user UID (will not change)

When the filter is done, man will call setuid(euid). Here, euid is the UID of the man user. (This ID is saved by man calling geteuid). This call is valid because the setuid parameter is equal to the saved set-user-ID. (This is why we need saved set-user-ID). At this point, we will have the following situation:

• real user ID = our user UID (will not change)

• effective user ID = man’s UID

• saved set-user-ID = man’s user UID (will not change)

Since the effective user ID is man, the man program can now operate its own files. By using saved set-user-ID in this way, we can use additional permissions through the program file’s set-user-ID at the start and end of the process. However, during this time, we are running with our own permissions. If we cannot switch back to saved set-user-ID at the end, we may retain additional permissions while we are running.

Now let’s see what happens when man starts a shell:

• Here the shell is started by man using fork and exec.

• At this point, both the real user ID and effective user ID are our ordinary user UID (see step 3), so the shell has no additional permissions.

• The started shell cannot access man’s saved set-user-ID (man), because the shell’s saved set-user-ID is copied from the effective user ID by exec.

• In the executing exec subprocess (shell), all user IDs are our ordinary user ID.

In fact, the way we describe how man uses the setuid function is not particularly accurate, because the program may set the set-user-ID to root. At this point, setuid will change all three UIDs to the ID you set, but we only need to set the effective user ID.

【About the Author】

Lü Kai: Shenzhen, with 9 years of work experience, Senior Chief Engineer at TPV Technology. Focused on software development, system operation and maintenance, content management, and mobile management, enjoys writing and sharing.

【About Submissions】

If you have original articles to submit, please send a message directly to the public account.

① Message format:【Submission】+《 Article Title》+ Article link② Example:【Submission】《Do not call yourself a programmer, my summary of over ten years in the IT workplace》:http://blog.jobbole.com/94148/③ Finally, please attach your personal profile~

Did you gain something from reading this article? Please share it with more people.

Follow ‘Linux Enthusiasts’ to enhance your Linux skills