In-depth analysis of Linux File Permission hiding

Article Title: detailed analysis on Linux File Permission hiding. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
Linux is a secure operating system designed based on files. Its file permissions are complex. You can use the stat command and lsattr command to display the details of a file:
$ Stat file1
File: 'file1'
Size: 11904 blocks: 24 io block: 4096 regular file
Device: 301 h/769d inode: 355982 links: 1
Access: (0755/-rwxr-xr-x) uid: (503/jack) gid: (503/general)
Access: 09:14:12. 000000000 + 0800
Modify: 20:41:21. 000000000 + 0800
Change: 18:56:25. 000000000 + 0800
　　
$ Lsattr file
---- I -- a ----- file
As you can see, the meaning of file permissions is relatively wide. First, let's look at-rwxr-xr-x. The first is the file type, which defines that users can only operate files in some way, the last nine digits are file access control information. The file license mechanism in linux divides users into three types: file owner u (user) and file owner group g (group) and other user o (other ). Three different types of users can have three different levels of permissions for files: read r (read), write w (write), and run x (execute ). Therefore, nine-digit permission information is formed, which is divided into three groups, corresponding to u, g, and o respectively. In addition, you can set the setuid and setgid bits to change the program execution identity. With the lsattr command, you can see the attributes of the file. The control bit includes asacddiijsttu, which can also control file access.
Due to limited space, it is impossible to analyze these issues one by one. This article focuses on analyzing the true meaning of w (write) in the File Permission and digging out the hidden details behind it, it tries to make good use of this key permission space to prevent system management errors.
In order to give a more intuitive explanation of the problem, this article uses the experiment operation method to analyze the problem step by step. To simplify operations, we use the o (other) group of permissions to perform experiments. The permission bits used in the experiment belong to o (other), and the operation users are non-root users and belong to o (other ).
Before the experiment, you must clarify the concept that a directory is also a file, which mainly includes two aspects of information, the file name under the Directory and the file inode number, there is a one-to-one relationship between them. However, the directory files are special and cannot be read or written using conventional methods. You must use dedicated commands of the system to perform operations. The ls command is actually used to read the directory files. The mv command and rm command are used to write the directory files.
Well, let's talk about the true meaning of w (write). In a word, w in linux File Permission limits the * content * of this file. The following experiment can be verified.
　　
Experiment 1: directory file:/test (rwx), common file:/test/file (r --). Current Directory:/test
　　
$ Echo "abc"> file
Bash: file: permission denied
I tried to rewrite the file content, but the file Permission was read-only. Obviously, the operation failed.
　　
$ Cat file
Hello world!
No problem. You can read the file content.
　　
$ Mv file file2
$ Ls
File2
What's going on? The file Permission is clearly read-only. Please note that, as mentioned above, the rw permission in the file only limits the content of the current file, the file name does not belong to the content of the current file. It is stored in the contents of the directory file at the upper level. On the surface, the mv command is for file. In fact, it is to rewrite the/test content, and then look at the/test permission, which is writable (rwx ). In order to protect files, many users do not need to set their permissions to read-only. This is very dangerous. It is true that it can achieve the purpose of protecting the file content (in fact, it may not be necessary, but it has been discussed in the supplementary content ), however, you cannot guarantee whether the file will be renamed or deleted. The safe way is to set the permission of the parent directory of the file to read-only. Of course, there are other methods, such as using the chattr + I command or mounting the file system in ro mode, but these are not covered in this article.
　　
$ Rm-f file2
$ Ls
$
For the same reason, we can delete file2. Unlike the previous operation, we are not modifying a/test record, but deleting a/test record.
　　
Experiment 2: directory file:/test (r-x), common file:/test/file (rw-), Current Directory:/test
　　
$ Echo "abc"> file
$ Cat file
Abc
The/test permission is read-only, but we rewrite the file content. Its permission is writable and of course there is no problem.
　　
$ Mv file file2
Mv: cannot move 'file' to 'file2': permission denied
$ Rm-f file
Rm: cannot remove 'file': permission denied
We already know that these two commands are not related to the file permission, but are modifying the/test content. Of course, the operation fails. Through the previous operations, we should clearly identify the actual object to be operated by the command so that we can correctly set the File Permission.
　　
Experiment 3: directory file:/test (rwx), common file:/test/file (r --), directory file:/test/dir (r-x), common file: /test/dir/file (rw-), Current Directory:/test
　　
$ Mv file file2
$ Mv dir dir2
$ Ls
Dir2 file2
It went quite well, because the permissions for/test/file and/test/dir parent directories/test were too loose, which was rwx.
　　
$ Rm-f file2
$ Rm-rf dir2
Rm: cannot remove 'dir2/file': permission denied
$ Ls-r
.:
Dir2
　　
./Dir2:
File
At this point, we are not surprised that the common file/test/file2 has been deleted, but the directory file/test/dir2 with the same status is safe. When rm-rf dir2 is executed, the system tries to delete the common file/test/dir2/file, which is equivalent to modifying the directory file/test/dir2, however, the permission is read-only and cannot be modified, which means that/test/dir2/file cannot be deleted, And/test/dir2 is dependent on/test/dir2/file, /test/dir2 will be retained.
Looking back at the previous operation (mv dir dir2), why can the directory file/test/dir be renamed? Because the renaming operation does not involve modification of its own content, only the content of the parent directory is modified. In the deletion operation, the content of the parent directory must be modified, however, you also need to modify your own content (because you want to delete the files in this directory), which is not allowed. If the/test/dir2 permission is writable or the directory does not have a sub-file, it will be deleted like/test/file2.
The previous operations show that the file has the following key states: read, modified, renamed, deleted, and executed. However, the system only has three permissions: read, write, and execute (rwx ). So will the system ignore the renaming and deletion operations? No. The system manages these two operations in the upper-level directory of the operated file. In what way can we manage it? The answer is that the directory regards all the files under it as its content. In this way, when a user renames or deletes a file, he performs write operations on the upper-level Directory, which belongs to one of the three permissions of rwx, and does not escape the management scope of the system.
Our brains are always active. We can imagine a variety of things and combine many simple things into complex things. Isn't that exactly what we did in the above experiments, we can design a lot of experiments like this, but the more we do, the more we seem to be confused (I already have a bit). Can you remember so much? OK, we may be able to think about it in a simpler way. We only need to pay attention to two aspects: first, we need to know what the contents of the Directory are; second, we need to understand w (write) in the file permission). Think about it, right?
　　
　　 Supplement:
In experiment 1, if you use vim to edit the file and force save (w !), Yes. This does not mean that vim can bypass the security mechanism of the system, but that vim plays a small trick. It deletes the file first and then generates a new file with the same name. But one exception is that when another hard-link file exists in this file, vim will refuse to force save the file. Think about it. After the delete operation, the file still exists, it is not actually deleted, and a new file is created. Although it has the same name, it is not the original file! I was also confused about this. I carefully read the source code of vim6.2 to find the answer. Interested readers can also take a look at the specific content in src/fileio. c.