(Transferred from chinaunix)
Ok, I will publish personal opinions on the part of Linux File Permission, and I don't see it. I only hope to give you some reference. ----------------------------- 1) Permission mode First, the file permission mode is information in Inode, a total of 12 BITs. 0000-00-00 PERMISSION MODE (0 and 1): 0 is closed, 1 is open. Each of these Bit means: SUID, SGID, Sticky_bit, User_read, user_write, user_execute, group_read, group_write, group_execute, tad, odser_write, Others_execute. Example: 100111101101 (Binary Mode) But in system application and management, we generally do not use binary mode (binary), but use Octal Mode or Text Mode. The Octal Mode is simply in converting binary. You can try Linux's BC command to count: $ echo "obase = 8; ibase = 2; 100111101101" | BC 4755 However, if you don't have a BC command or calculator, then it is not possible. Difficult: A 3bit of the 3bit: 000: 0 001: 1 010: 2 011: 3 100: 4 101: 5 110: 6 111: 7 Then, divide 12bit into 4 groups: 100, 111, 101, 101 followed by the above table Lightly conversion: 4, 7, 5, 5 However, on the representation of Text Mode, some are more complicated because 12 letters are compressed into 9. However, its principle is not difficult: * Disperse the first set of BITs in the X position of the last three groups: SUID covers UX then indicates that the SGID is blocked by the SGID and then use S or S to indicate the StickBit cover off OX and then use T or T indicate * If X is set, use lowercase; if X is not set, it is uppercase * If a bit indicates (RWXST) in the open state (RWXST) in the open state, (or s, t).
The following is the previous example: [Code: 1: 45BF2E0C43] binary: 100 111 101 101 TEXT: RWS RX RX Octal: 4 7 5 5 [/ Code: 1: 45BF2E0C43] The following is two examples: [Code: 1: 45BF2E0C43 ] binary: 010 111 111 101 001 111 111 111 TEXT: RWX RWS RX RWX RWX RWT Octal: 2 7 7 5 1 7 7 [/ Code: 1: 45BF2E0C43] 2) UGO Use the ls -l command to get each one The following information: file_type & permission_mode, link_count, user, group, size, modification_time, file_name We can see ten letters from the leftmost field, the first is: File Type is the remaining nine for Permission Mode, and divided into three groups : User, Gorup, Others. For each user, the three groups of UGO can only choose one: * If the UID is consistent with the File UID, use User and ignore Group & Others. * If the UID is inconsistent with the File UID, then the GID (S) is consistent with the File GID. Take Group to ignore USER & OTHERS. * If the UID is inconsistent with the GID, Others and Ignore USER & Group. (Note: You can enter the ID at any time this command knows that the UID and GID (s) you are using.) 3) RWX Once the UGO Permission referred to by the user can be determined, then see it later The representative of Permission. In fact, RWX is different from the following two file types: * Take the beginning of the file: R: The contents of the file can be read the contents of the file x: Executable and Generating Process * with D DIRECTORY: R: You can read the content under this directory (ie, file and sub Dir) W: can modify the content under this directory (ie, increase or decrease the file and sub Dir) x: can enter Under this directory (ie access, such as access control cards) where Directory's X is the least understood: Even if you have rw to DIR, if there is no X, then you can't go in, it is like you are the owner of your own suit. But I can't enter the door of the apartment.
However, when you have RWX permissions to a Directory, some file / dir inside you don't have RWX permissions, just put some items that don't belong to your items, * You can't open it (no R ) * You can't steal the dragon to turn the phoenix feet (no W) * You can only open your eyes but no blessing (no x) but you can still enter the trash ... Because you are in your suites: * To all items (R) * can move into the moving out or DIY item (W) * You have a key entry (X) 4) SUID, SGID, Sticky Bit Suid / SgID What is the procedable file? Uid / GID: If there is, it is inherited from the UID / GID of the FILE itself. If no set, inherit from Parrent Process (usually the shell). Sticky_bit is not satisfactory for File in a modern Linux system. But Suid has no meaning to Directory (there is no settings), but SGID will affect Directory, which will affect the new file / dir's GID under this directory: if there is a set, GID from DIR (if it is new Dir, Its SGID will also inherit). If it is not set, the GID is inherited from the process of generating new file / dir. As for the Directory's Sticky bit, the role of protecting the file: If there is no setting, the user can delete the file in DIR as long as the DIR is W Permission (please refer to the foregoing). If there is a set, the user needs to be in addition to W Permsissin, and one of the following two conditions is required: * The UID of the user must match the directory where the file is located, or the user's UID must be consistent with the deleted document. 5) Umask umask's role is to cancel the Permission when new files or directories. Its algorithm is: New Dir: (NOT UMASK) and 0777 (000, 111, 111, 111) New File: (Not Umask) and 0666 (000, 110, 110, 110) where NOT (BitWise) and AND is Lu Luo operation: NOT: 1 change 0, 0 1 and: 1 && 1 = 1, 0 && 0 = 0, 1 && 0 = 0, 0 && 1 = 0 as an example of 0033 UMASK: New Dir: * 0033 Replacement to Bit: 000, 011, 011 * NOT 0033 Get: 111, 111, 100, 100 * and Directory 0777: 000, 111, 111, 111 * Make and operate: 000, 111, 100, 100 * Go to Octal is: 0, 7, 4, 4 new file: * 0033 to Bit 0033: 111, 111, 100, 100 * and Directory 0666: 000, 110, 110, 110 * Make the AND operation: 000, 111, 100, 100 * turn For Octal is: 0, 6, 4, 4 to use subtraction, I am afraid I will not be allowed to New File.
