Linux file permissions

Linux file permissions

Each file belongs to one user and one group. This is the core of the permissions model in Linux. Each file has a 10-tuple representing the file's type and file owner, the group user to which the file belongs, and other users ' permissions to manipulate the file.

For example, a 10-tuple of an ordinary file

-rwxr-xr-x 1 root wheel 430540 Dec 18:27/bin/bash

The first character in the field (-) specifies the type of the file, in this case it is a regular file, and the remainder of the field consists of three triples of characters. The first ternary character group represents the permissions of the file owner (read, write, execute), the second represents the permissions of the group of files (read, execute), and the third represents the rights of all other users (read, execute)

Permissions for the Directory

When you look at permissions from a directory perspective, the situation is a little different. The directories use the same permission flags, but they are interpreted as representing slightly different meanings. For a directory, if the "read" flag is set, you can list the contents of the directory; "Write" means that you can create a file in the directory, "execute" means that you can enter the directory and access any subdirectories inside. Without the "EXECUTE" flag, the file system objects within the directory are inaccessible, and the Execute permission bit for the directory is called the search bit. Without the "read" flag, file system objects within the directory are not viewable, but as long as someone knows the full path of an object on disk, they can still access objects within the directory.

Process Operation permissions

Do we know that different users have different permissions on files? So how does the operating system determine if an application has the appropriate permissions to manipulate the corresponding files?

In fact, each process is maintained with the following 6 IDs:

Real identity: Real UID, Real GID

Valid identity: Effective UID, effective GID

Storage identity: Saved UID, saved GID

Where the real identity is the identity we use to log in, and the identity that is checked when the process really goes to manipulate the file

When the process is fork, both true and valid identities are copied to the child process. In most cases, the true identity and valid identity are the same. When Linux finishes booting, the INIT process executes a login child process. We pass the user name and password to the login child process. After querying the/etc/passwd and/etc/shadow and determining its legitimacy, login runs (with exec) a shell process, and the real identity of the shell process is set to be the user's identity. Since the child processes that fork this shell process will inherit the true identity thereafter, the true identity will persist until we log out and sign in another identity (when we use SU as root, we are actually logged in as root, and then the real identity becomes root).

A stored identity is another identity other than a real identity. When we execute a program file as a process, the owner of the program file (owner) and the owning group (owner) can be stored as the process's storage identity. During the subsequent process, the process will be able to choose to copy the real or stored identity to a valid identity to have the true identity or the right to store the identity. Not all program files are set to store identities during the execution of the process. The program file that needs to do this will change the x of its nine-bit (bit) permission's execution bit to S. At this point, this bit is called the set UID bit or set GID bit.

When a bit of "suid" is set for an executable program, it runs on behalf of the owner of the executables, not the person who initiates the program. Set the program's valid user ID to the user ID of the file instead of starting the program's user ID and saving the file's user ID to the Stored User ID.

For example, if the owner of the file is the root user, and the set user ID bit of the file is set, then no matter what user starts the program, the program's valid user ID can root, and it will have the root permission to manipulate the file.

Each time the process opens, creates and deletes a file, the kernel sets permissions on the file

1. If the process's valid user ID is 0 (superuser), access is allowed.

2. If the owner ID of the file is the valid user ID of the process, then the owner's appropriate access permission bit is set to allow access, otherwise access is denied. (You will not be able to determine whether the program's group ID has the appropriate permissions, even if the group user or other user has the appropriate access rights)

3. If the valid group ID of the process is equal to the group ID of the file, access is allowed if the appropriate access permission bit for the group is set, otherwise access is denied. (No other user's access rights will be viewed again.)

4. View the appropriate permission bits for other users

When we open any type of file by name, we should have execute permission on each directory that the name contains.

For example, to open the file/home/ghbai/test.h, you need to have execute permissions on the directory/,/home,/home/ghbai

In order to delete a file requires write permission to the directory where the file is located, no permissions are required on the file itself

In order to create a new file in a directory, you must have write permission to execute permissions on the directory

New file

When a new file is created, the user ID of the file is set to a valid user ID for the process

The group ID of the newly created user in Linux depends on whether the setting group ID bit of the directory it resides in is set (we talked about the setting ID of the executable file, set the group ID, the executable file and the directory's setting group ID bit the meaning is not the same), if this bit of the directory has been set, The group ID of the new file is set to the group ID of the directory, otherwise the group ID of the new file is the valid group ID of the process

Umask

1. When a process creates a file or a new directory, it uses the file mode to create the mask word, and the umask function creates a mask for the process settings file mode.

On Linux systems, the default value of Umask is typically 0022, which allows others to read your new files if they can
Get them), but cannot be modified.
To make the new file more secure by default, you can change the Umask setting:
$ umask 0077
Umask will ensure that the group and other users have absolutely no permissions on the newly created file. So, how does umask work?
Unlike the general permissions of a file, umask specifies which permission should be closed.

Using the Umask function in the program

#include <sys/stat.h>

mode_t umask (mode_t cmask);

2. Changing the file mode of a process creating a mask word does not affect the parent process

3. The new directory created must have Execute permissions

Chmod Chown Chgrp

1. chmod can change file permissions, but only the file owner or root user has permission to execute a file chmod

2. Chown can change the file owner, only the root user has permission to change the file owner using Chown

3. Chgrp can change the file group, only the owner of the file has permission to change the file's group ID, and can only change the file's group ID to the group where the file owner is located

directory Sticky bit

By default, the Linux directory behaves in a way that is not ideal in all cases. In general, as long as a

The directory has write access, and anyone can rename or delete files in that directory. For a directory used by individual users, this row
is very reasonable.
However, this behavior can be problematic for directories used by many users, especially/TMP and/var/tmp.
Because anyone can write these directories, anyone can delete or rename any other person's files-even if they don't belong to
They are! Obviously, when any other user can enter "rm-rf/tmp/*" at any time and damage everyone's text
It is difficult to use/TMP for any meaningful file.
Fortunately, Linux has something called a "sticky bit" (sticky bit). When a sticky bit is set for/tmp (with
chmod +t), the only person who can delete or rename a file in/TMP is the owner of the directory (usually the root user)
, the owner of the file, or the root user. In fact, all Linux bundles are enabled by default with/tmp sticky bits,
You can also find that sticky bits work well in other situations as well.

Reference documents:

1. http://www.cnblogs.com/vamei/tag/Linux/

2. Advanced programming of the UNIX environment

3. http://zhangfeikr.blog.51cto.com/1999170/396541