Linux File Permissions

Linux File permissions have been idle for the past few days. Write something to get it, and 80% is a reference. I. The file type, owner, owner group, and other people's permissions will be used by ls-l. There will be many lines in the future. Then: This representation method has a total of ten "9 8 7 6 5 4 3 2 1 0-r w x r-x www.2cto.com 9th bits representing the file type, it can be p, d, l, s, c, B, and -: p indicates the named pipeline file d indicates the directory file l indicates the symbolic connection file-indicates the common file s indicates the socket file c indicates the character device file B indicates the 8-6 bits, 5-3 bits, and 2-0 bits of the block Device File bits indicate the permissions of the file owner, permissions of users in the same group. permissions of other users are in the form of rwx:
In the UNIX implementation, the File Permission is represented by 12 binary bits. If the value on this location is 1, the File Permission has the corresponding permissions: 11 10 9 8 7 6 5 4 3 2 1 0 s g t r w x 11th bits are SUID bits, 10th bits are SGID bits, the 9th bits are sticky bits, and the 8-0 bits correspond to the preceding three groups of rwx bits. 11 10 9 8 7 6 5 4 3 2 1 0 the value of-rwsr-xr-x above is: 1 0 0 1 1 1 0 1 1 0 1 1 1-rw-r-Sr -- Value: 0 1 0 1 0 1 0 0 0 1 0 0 0 0 0 0
The command to add SUID and SUID to the file is as follows: chmod u + s filename setting SUID bit chmod u-s filename removing SUID setting chmod g + s filename setting SGID bit chmod g-s filename removing SGID setting another way is to use the chmod command octal represents the setting of the method. If you understand the previous 12-bit permission notation, www.2cto.com is also very simple.
Ii. Detailed parsing of SUID, SGID, and Sticky Bit we often see that, in many cases, how can we set the permissions for a file using methods such as 4656? This is related to Set UID, Set GID, Sticky Bit: Set UID will create s and t permissions, so that when the general user executes some programs, you can temporarily have the permissions of the owner of the program. For example, we know that the account and password are actually stored in/etc/passwd and/etc/shadow. The permission for the/etc/shadow file is "-r --------". Its owner is root. In this permission, only the root user can "force" the storage, and others cannot even view it. However, when I use dmtsai as a general identity user to update my password, I use the/usr/bin/passwd program, but I can update my password. That is to say, the general identity user dmtsai can save the/etc/shadow password file. How is this possible? Clearly/etc/shadow indicates that dmtsai has no access permission. This is because you have the s permission to help. When the s permission is Set to user x, it is similar to-r-s -- x, which is called Set UID (SUID for short). This UID indicates the User ID, user indicates the owner (root) of the Program (/usr/bin/passwd ). Then, we can know that when the dmtsai user executes/usr/bin/passwd, it will "Temporarily" Get the root permission of the file owner. SUID can only be used in "binary file". Because SUID has the permissions of the file owner during execution, SUID can only be used for binary files, it cannot be used in batch files (shell scripts. This is because the shell script only calls many binary execution files for execution. Therefore, the SUID permission part depends on the program settings called by the www.2cto.com shell script, rather than the shell script itself. Of course, SUID is invalid for the directory. Pay special attention to this. Set GID further, if the s permission is in the user group, it is Set GID (SGID for short. SGID can be used in two ways. File: If SGID is set to a binary file, its valid user group (valid group) is used to execute the program no matter who the user is) the group id directory of the user group owner of the program: If SGID is set to A directory, the user group of the files or directories created in directory A will be changed, it will be the user group of this A directory. Generally, SGID is mostly used in project development by a specific multi-person team and rarely used in the system. Sticky Bit: this Sticky Bit is only valid for directories and has no effect on files. The role of SBit on a directory is: "If a user has the permissions of w and x under a directory with SBit, when a user creates a file or directory under this directory, only the file owner and root have the right to delete the file ". In other words, when user A has A group or other project under directory A and has w permissions, this means that user a can perform operations such as "delete, rename, and move" on any directories or files created in the directory. However, if you add the Sticky bit permission to directory A, you can only delete, rename, or move the files or directories you have created. For example, the/tmp permission is "drwxrwxrwt". With this permission, anyone can add or modify files in/tmp, however, only the creator and root of the file/directory can delete their own directories or files. This feature is also important. You can perform a simple test like this:
1. log on to the system as root and enter/tmp. 2. touch test and change the test permission to 777. 3. log in as a normal user and enter/tmp. 4. Try to delete the test file.