As mentioned in the file-related commands: "File extensions in Linux are for "reference" only; for example, Linux executables do not use ".exe" as an extension like in Windows.
So how does Linux determine which files are executables? Why can't you enter certain directories when logged in as a regular user? Why can't you delete any files except those you created? Why are many files unreadable? Everything is related to file "ownership" and "permissions". Before we explain, let's experience it firsthand.
Example: (Test with a regular account, do not log in as root because the Superuser is not subject to permission restrictions)| $ cd /root ←← Try entering the `/root` directory bash: cd: /root: Permission denied ←Permission denied $ cat /etc/shadow ← Try reading the account password information file `/etc/shadow` cat: /etc/shadow: Permission denied ← Permission denied $ cp /etc/shadow ~/ ←Try copying `/etc/shadow` cp: cannot open '/etc/shadow' for reading: Permission denied ←Permission denied $ rm -f /bin/ls ←Try deleting the command `/bin/ls` rm: cannot remove `/bin/ls': Permission denied ←Permission denied |
When logging into Linux, there are actually two identities: the logged-in user and the group accompanying the logged-in user. If a file is created, this file will record these two identities.
Example: :| $ echo "hello Wold" > /tmp/myfile ←Create a file `myfile` $ ls -l /tmp/myfile ←Use `ls -l` to list detailed file information -rw-rw-r-- 1 aaa aaa 11 2011-10-10 10:10 myfile ←The red marked text is the user, the green marked text is the group |
Permissions
File permissions determine whether the owner (user/group/other) has the ability to "read," "write," or "execute" the file (Linux executables are not determined by file extensions, but by having "execute" permissions).These file permissions, except for the execute permission for root, are otherwise ineffective. This means that if you log in as "root", you can do anything you want, such as deleting or tampering with files, as if there were no restrictions.
Let's review the example when introducing the ls command, which uses ls -l to list detailed file information, as follows:
| $ ls -l ← List detailed file contents | |||||||
| drw-rw-r-- | 1 | aaa | aaa | 292 | 2011-09-07 | 11:44 | myfile |
| ↑ | ↑ | ↑ | |||||
| permission | user | group | |||||
The characters "r", "w", and "x" (the order "rwx" is fixed) appearing in the file permissions field represent read, write, and execute permissions for the file, respectively. Permissions that are not set are displayed as "-". For example,"r--" means only read permission.
The table below shows the effects of permissions on files:| Permission | Effect on File |
| r (read) | Can view the content of the file, e.g., can be read using cat, less, or other tools. |
| w (write) | Can modify its content, e.g., can be modified using vi or by redirection for appending. |
| x (execute) | If it's an executable file, it can be executed. However, if it's a shell script, it also needs read permission to be executed (because the shell needs to read the file). |
| $ ls -l /tmp/myfile -rw-rw-r-- 1 aaa aaa 11 2011-10-10 10:10 myfile |
In the example above, the ls -l output shows permissions as "rw-rw-r--". The first character in red, "r", means the owner (account aaa) has "read" permission for this file. The second character, "w", means the owner has "write" permission. The third character, "-", means the owner has no execute permission.
Similarly, the green characters mean that the "aaa" group also has read and write but no execute permissions for this file, while "other" (anyone not defined as owner or in a group) can only read but not write.
Next, let's test with different accounts.| $ echo "hello Wold" > /tmp/myfile ←Create a file `myfile` $ ls -l /tmp/myfile ←Verify permissions -rw-rw-r-- 1 aaa aaa 15 2011-09-07 00:46 /tmp/myfile ←Same owner/group can read and write, but other can only read $ cat /tmp/myfile←Try reading (testing `read` permission) Hello Wold $ echo 'Hello Linux' >> /tmp/myfile ←Try changing the content of `myfile` (testing `write` permission) $ cat /tmp/myfile ←Verify Hello World Hello Linux $ su bbb ←Temporarily change to another account Password: ←Enter the account password $ cat myfile ←Test `read` permission Hello World ←This file has `read` permission for "other", so everyone else can read files created by account `aaa` Hello Linux Hello Linux $ echo 'Hello Unix' >> /tmp/myfile←Try adding content to `myfile` bash: /tmp/myfile: Permission denied ←Permission denied (because `other` has no `write` permission for this file) |
| $ ls -l /etc/shadow ←List detailed file information for the account password file `/etc/shadow` -r-------- 1 root root 1147 2011-09-07 11:47 /etc/shadow |
In the example above, the file "/etc/shadow" is the shadow file for account passwords. Although its content is encoded in ASCII text, it has been encrypted from plaintext to ciphertext. Because this file is very important and could be cracked by hackers to find login passwords for each account, its owner and group are both root, and its permissions are displayed as "r--------", meaning this file can only be read, not written to, even if logged in as "root". However, "cannot write" is more of a declaration than a practical restriction for "root", as the "root" account has unlimited privileges.
Let's look at what the owner and permissions of a typical executable file look like.
Example:| $ ls -l /bin/cat -rwxr-xr-x 1 root root 23360 2007-10-31 11:52 /bin/cat |
In the example above, the cat command's owner and group are "root", and it has full read, write, and execute permissions. For non-root owners and groups, users of this command are considered "other" and can only read and execute.
Additionally, some commands like cp change the owner and group of the destination file to that of the operator. The purpose of this is to allow the copied file to be fully controlled.
Example: (Please test with a regular account)| $ cp /bin/cat ~/ ←Copy `/bin/ls` to the home directory $ ls -l /bin/cat ~/cat ←List these two files for comparison -rwxr-xr-x 1 root root 23360 2007-10-31 11:52 /bin/cat -rwxr-xr-x 1 aaa aaa 23360 2011-10-10 10:10 ./cat ←Notice how the owner and group of the copied file changed to that of the operator |
| permission | Effect on Directory |
| r | List files or subdirectories within the directory (e.g., ls can display files within the directory, but cat cannot read files within the directory). |
| w | Add, delete, or rename files within the directory (e.g., rm , cp , or mv can be used on files within the directory). |
| x | Enter the directory or execute programs within the directory (e.g., cd can enter the directory). |
| $ ls -l /home ←List permissions for all home directories within `/home` drwx------ 28 aaa aaa 4096 4096 2-11-10-11 15:41 aaa drwx------ 3 bbb bbb 4096 4096 2-11-10-03 19:59 bbb $ ls /home/bbb ←See what's inside someone else's home directory ls: cannot open directory /home/bbb: Permission denied ← No permission |
If file and directory permissions contradict each other, which one should be obeyed? If there are laws, there will be loopholes; if there is software, there will be bugs. Of course, we need to find ways to prevent them, and that's where special permissions come in handy.
Special permissions borrow the "x" (execute) position for setting and displaying. If "t" or "s" appears in the "x" permission position, it means special permissions have been set.
The purpose of setting SBIT for a directory is to ensure that only the owner of a file in a public directory can delete or rename it (except for root, of course). Let's illustrate with an example:
| $ ls -ld /tmp drwxrwxrwt 9 root root 4096 2011-10-16 12:11 /tmp ←Note the `rwt` in the "other" permissions of `rwx`. The lowercase `t` is the sticky bit. |
The Sticky Bit only applies to directories, not to files.
Example: (Test with a regular account)| $ cd /tmp ←Enter the `/tmp` directory $ echo 'Hello' > file ← Create a file `file` $ ls -l file ←Use `ls -l` to list detailed file information -rw-rw-r-- 1 aaa aaa 6 2011-10-10 10:10 file ←The owner and group of the file are both `aaa` $ su bbb ←Use the `su` command to temporarily change to another user Password: (Enter the other user's account password) $ mv file fileB ←Try renaming as another user mv: cannot move 'file' to 'fileB': Operation not permitted ←Permission denied $ rm -f file ←Try deleting a file that doesn't belong to oneself rm: cannot remove 'file': Operation not permitted ←Permission denied $ exit ←Return to the original logged-in account $ mv -v file fileB ←Try renaming 'file' -> 'FileB' ←Successful $ rm -v fileB ←Try deleting removed 'fileB' ←Successful |
| $ ls -l /usr/bin/wall -r-xr-sr-x 1 root tty 10712 2007-10-11 03:54 /usr/bin/wall ←Observe, the group is `tty`, but why did the `x` in permissions change to a `lowercase s`? A lowercase `s` appearing in the group indicates SGID. |
Before explaining, let's clarify the purpose of the wall command. wall is short for "write all," and its function is to send messages to every terminal (tty). For example, if an account logs in to tty1 and types wall 'Happy New Year' or uses input redirection wall < message_file, anyone else logged in to other ttys at the same time will receive the broadcast message from the tty1 logged-in user.
However, to receive a broadcast message from a certain tty (terminal), everyone must at least be in the same group. Therefore, the solution is that whoever executes the wall command (the wall command's group is tty), regardless of their original group, will temporarily become the group that the executable belongs to (in this example, the group is tty, and the tty group is a system default). As soon as this command finishes, they immediately return to their original logged-in group.
Similar commands with SGID include /usr/bin/write, /usr/bin/locate, etc.
The SGID file permission display will show "s" in the original group's "x" position.
If used on a directory, any file placed in a directory with SGID will change to that directory's group. This is primarily used for group collaborative work.
| $ ls -l /usr/bin/chsh /etc/passwd ← List file information for `/usr/bin/chsh` and `/etc/passwd` -rw-r--r-- 1 root root 1783 2015-07-21 16:58 /etc/passwd -rws--x--x 1 root root 14472 2007-10-17 04:48 /usr/bin/chsh ←Notice the `lowercase s` in the owner's permissions, which is SUID. |
The chsh command is used to change or list available shells. When changing the shell, chsh will modify the configuration file "/etc/passwd" (the last few lines of this file define the default shell for each account). But here's the problem: the file "/etc/passwd" only has write permissions for "root". How can a regular account possibly modify "/etc/passwd"?
Therefore, the solution is to set SUID for the chsh command.
So, no matter who executes this command, when it runs, it will temporarily become the owner of that file (root), thus having the authority to modify the "/etc/passwd" file.
Similar commands with SUID include "/bin/mount", "/usr/bin/passwd", etc. The SUID file permission display will show "s" in the original owner's "x" position.
| special permission | file/directory | Effect | Caveat | ls -l Permission Display |
| Sticky bit | Directory | In a directory with Sticky bit, only the file owner or "root" can delete or rename the file | Others must also have "x" permission. | --- --- --t |
| Set Group ID | File | For executable files only; temporarily changes to the file's group during execution. | Group must also have "x" permission. | --- --s --- |
| Directory | Any file placed in the directory will become the group of this directory. | |||
| Set User ID | File | For executable files only; temporarily changes to the file's owner during execution. | User must also have "x" permission. | --s --- --- |
chmod accepts "Numeric representation" and "Symbolic representation." The proportion of users for these two methods is about equal. Numeric representation is shorter, but non-engineering personnel might find "decimal to binary" daunting, while symbolic representation can be more verbose.
There are eight possible permission states, represented by numbers 0-7 as follows:
| Numeric Permissions | ||
| # | Permissions | rwx |
| 7=111BIN) | full | rwx |
| 6=110 BIN) | read & write | rw- |
| 5=101 (BIN) | read & execute | r-x |
| 4=100 (BIN) | read only | r-- |
| 3=011 (BIN) | write & execute | -wx |
| 2=010 (BIN) | write only | -w- |
| 1=001 (BIN) | execute only | --x |
| 0=000 (BIN) | none | --- |
| $ echo 'hello world' > myfile ←Create a file "myfile" $ ls -l myfile ←Use ls -l to list verbose file information -rw-rw-r-- 1 aaa aaa 12 2011-10-22 16:27 myfile ←Default text files usually allow others to read only $ chmod 660 myfile ←Change permissions to "-rw -rw- ---", meaning others can no longer read $ ls -l myfile ←Check if permissions have changed -rw-rw---- 1 aaa aaa 12 2011-10-22 16:27 myfile |
| $ chmod 777 file ←Permissions are rwx rwx rwx $ chmod 644 file ←Permissions are rw- r-- r-- $ chmod -R 711 dir/ ← Recursively change permissions of all files in the directory $ chmod 000 file ←Permissions are --- --- ---, no permissions at all, what's it for?? If it's a file, usually only "root" is given read/write access (possibly a confidential document) |
| Special Permission Numeric Representation | |
| # | Special Permission |
| 4=100 (BIN) | SUID |
| 2=010 (BIN) | SGID |
| 1=001 (BIN) | SBIT |
To set special permissions, their values should be added to the leftmost digit in the original numeric representation, thus requiring four digits in total.
Example:| $ cp /bin/cat ~/my_exec ←Copy an executable file to modify $ chmod 4755 my_exec ←Add SUID to the executable file's permissions (SUID value is 4) $ ls -l my_exec ←Verify -rwsr-xr-x 1 aaa aaa 23360 2007-10-31 00:52 my_exec ←The lowercase "s" in the owner's permission is SUID |
However, special permissions cannot be set randomly, otherwise invalid special permissions might result.
Example: (Continuing the previous experiment)| $ echo "hello" > my_text ←Create a text file $ chmod 4640 my_text ←Change text file permissions, remove "x" permission for user, and add SUID $ chmod 1654 my_exec←Change executable file permissions, remove "x" permission for other, and add SBIT # ls -l my_text my_exec ←List "root_file" and "root_cat" in verbose format to confirm -rw-r-wr-T 1 aaa aaa 23360 2007-10-31 00:52 my_exec ←SBIT's lowercase "t" became uppercase "T"?? -rwSr----- 1 aaa aaa 6 2011-10-23 14:59 my_text ←SUID's lowercase "S" became uppercase "S"?? |
In the syntax, [ugoa]: "u" stands for user; "g" for group; "o" for other; "a" for all, i.e., u+g+o. (If "a" is omitted, it also means u+g+o).
In the syntax [+ - =]: "+" means add permission; "-" subtract permission; "=" directly set permission. The last [st] in the syntax is special permissions , where "s" is SUID or SGID , and "t" is Sticky bit . When using symbolic representation, it's best to add the option "-v" or "-c" to display the process of permission changes for easy confirmation.| $ chmod -v a=rw file ←Set file's user, group, other to have rw permissions mode of `file' changed to 0666 (rw-rw-rw-) $ chmod -v =rw file ←Same as above (omit "a") $ chmod -v ug=rwx,o-r file ←User and group permissions are "rwx", remove "r" permission for other mode of `file' changed to 0772 (rwxrwx-w-) $ chmod ug+x file ←Add "x" permission to owner and group (rest unchanged) $ chmod u-x,g+rw file ←Remove "x" from owner, add "rw" to group (rest unchanged) $ chmod u+s file ←Add SUID $ chmod g-s file ←Remove SGID $ chmod +t dir ←Set SBIT (sticky bit can only be used on other, so "o" in o+t can be omitted) $ chmod a=rwx,o+t dir ←Set directory's owner, group, other = "rwx" and add Sticky bit |
| $ umask ←If no options, output displays default permissions when creating files or directories 0002 |
| umask | File Permissions | Directory Permissions |
000 |
666 (rw- rw- rw-) |
777 (rwx rwx rwx) |
002 |
664 (rw- rw- r--) |
775 (rwx rwx r-x) |
022 |
644 (rw- r-- r--) |
755 (rwx r-x r-x) |
027 |
640 (rw- r-- ---) |
750 (rwx r-x ---) |
077 |
600 (rw- --- ---) |
700 (rwx --- ---) |
277 |
400 (r-- --- ---) |
500 (r-x --- ---) |
From the table, umask=0002 means that the permissions for creating a file are "rw- rw- r--", and for a directory, they are "rwx rwx r-x". To change the default file creation permissions, simply enter umask [#][###] ("#" is a digit, refer to the table above, and the first "#" is for special permissions , which is generally not changed, so it remains 0).
Example: (This is tested as a regular user; results may vary if tested as "root")| $ umask ←Check default permissions 0002 $ echo 'umask file1' > umask_0002 ←Create file "umask_0002" $ umask 0027 ←Change default permissions to "0027" (rw- r-- ---) $ umask ←Confirm if default permissions have changed 0027 ←Changed to "0027" $ echo 'umask file2' > umask_0027 ←Create file "umask_0027" with umask=0027 $ ls -l umask_0002 umask_0027 ←List permissions of both files to compare -rw-rw-r-- 1 aaa aaa 12 2011-10-10 10:10 umask_0002 ←Note the different permissions for the two files -rw-r----- 1 aaa aaa 12 2011-10-10 10:11 umask_0027 |
| Syntax: chattr [-otpiton][+-=][mode] file/directroy | |||
| Command name/Function/Command user | Options | Function | The attributes of mode are [aAcdDisSu], each meaning is |
| chattr/ change attribute/ Any(mainly for Superuser) |
-R | Change the attributes of files recursively | "a": Used for files can only be accumulated, can not be deleted. When used in a directory, only the content of the files in the directory can be modified, but the files cannot be added or deleted. And only "root" can use . "A": Do not update the atime of the file "c": Automatically compress files when archiving, and automatically decompress when reading "d": Exclude dump data, that is, this file will be excluded when executing the dump command "D" If the directory is set, the data in the buffer memory will be saved to the hard disk synchronously "i": Make the file indestructible; including cannot delete, rename, modify content, change permissions, etc. and only "root" can use it "s": Destroy corpses and wipe out traces. When a file is deleted, the block of the file will be filled with 0 (so that those who are interested cannot restore the file) "S": When archiving, do not write to the buffer memory first, but directly write to the hard disk (the performance is poor, but it can prevent file loss when the power is cut off) "u": Contrary to "s" destroying and erasing traces, when the file is just deleted, only the inode is deleted, so that the file can be saved if you regret it in the future "maybe" |
| -V | The process of displaying transaction attributes | ||
From the usage of chattr's mode, it can be seen that many attributes are designed to regulate "root" (Superuser). For example, attribute "a" is mainly used for log files that accumulate, and even with the "root" account, this file cannot be deleted. Attribute "i" in mode means the file cannot be touched at all. When deleting a file, Linux, for performance reasons, only deletes the file's inode and does not truly clear the data (block). If it's confidential data and you're afraid of it being recovered upon deletion, adding attribute "s" is the way to go.
Experiment: (Logged in as "root", for testing)| # echo '123' > myfile ←Create file "myfile" # chattr +a myfile ←Set "a" attribute: only append, cannot delete # rm -f myfile ←Try to delete rm: cannot remove `myfile': Operation not permitted ←Permission denied # echo '456' > myfile ←Try to overwrite bash: myfile: Operation not permitted ←Permission denied # echo '456' >> myfile ←Try to append # cat myfile ← verify 123 456 # chattr -V -a myfile ←Remove "a" attribute so it can be deleted chattr 1.40.2 (12-Jul-2007) Flags of myfile set as ---------------- |
| # chattr =aAdS file ←Set file to have "a", "A", "d", "S" attributes # chattr -V +i -ad file ←Add "i" attribute to file and remove "a", "d" attributes |
| Syntax::lsattr [-otpiton] file/directroy | ||
| Command Bane/Function/Command User |
Options | Function |
| lsattr/ list attrbute/ Any |
-a | List attributes of all files and directories, including hidden files, current directory, and parent directory. |
| -d | Only list directory attributes. | |
| -R | Recursively list attributes of files and subdirectories within a directory. | |
| # echo > file # chattr =aAdS file ←Set the file to have "a", "A", "d", "S" attributes # lsattr file ←Display file attributes --S--adA-------- file |
| # lsattr -a ←List the attributes of all files in the directory (including the working directory and its parent directory) -----a---------- ./. ←Attributes of the working directory ---------------- ./.. ←Attributes of parent directory -----a---------- ./jun ←Attributes of file in directory |