Everything is XX. This is the cry of both the essence and the whole theory!
Reference. There is no direct relationship between the tree-like model and everything, but their experiences are similar.
Recently I read a book bought by my wife, "visual beauty". In ancient times, people had a special liking for trees. They finally included the organizational structure, including the classification of all trees. After reading the subsequent chapters, I found that the original tree model was not the essence of everything, it was produced by humans in the new moon in the United States of Ethiopia around 10000 BC. That is, the agricultural revolution led to the idea of tree models.
The tree model is very orderly. Any two nodes are connected in one way, and any node can be traced and traced. Everything looks perfect. It can even cover everything in the world. Taking taxonomy as an example, the ancient Greek philosopher pofeili's tree is a typical one. He defined all attributes in advance, then, things are classified by "with this attribute" or "without this attribute". In the end, all things can find a leaf in this tree as their own position.
When everything works well under the tree model (including economic, political, and corporate operations), people have discovered that the more fundamental thought is the Internet, as a result, the tree model is no longer applicable when the link is everything. Today, we are in a complex network era, where complex networks are everywhere, including social circles, cities, stocks, meteorology, and our brains. However, we cannot deny the ancient saying that "everything is a tree". It is because of their simple model that human civilization will be born and develop. Today we are confused about chaos and eventually we will find that, chaos is an ordered chaos.
What I want to say is that although some ideas are ultimately proved wrong, they must be said at the beginning, because Simplicity is the driving force for moving forward, when encountering obstacles or bottlenecks, things will develop horizontally, that is, moving toward complexity and chaos. However, complexity and chaos are not the goal, but they are trying to find a hole to continue, some adjustments may be made, and then the system continues to grow up simply after the obstacle is crossed, just like the growth of plants. Everything is a file, one of UNIX's creden。, and now it has encountered some challenges.
Procfs, a process file system, is an inverse example of all files. A memory file system that displays Process status and related data in UNIX systems. It has an ancient history, and may have become the de facto evangelist of "Everything is a file" at the very beginning. You can see that even the Process status can be represented as a file.
Everything is a file. The original meaning is that file operations have a unified and simple interface. In the 10000 years of computer science, all operations can be attributed to read, write, and control. Therefore, read, write, and ioctl are the oldest file operation set, if you try to classify all operations into file operations, you need to establish a series of mappings that abstract the mechanisms and policies. This ing is one-to-many, A unified operation primitive representation mechanism, and multiple different operation implementations act as policies. In the end, VFS was born!
With VFS, it is easy for people to implement everything as a file system. Linux is still doing this until today, and it will stop like UNIX. When this kind of thing is done enough, when there are more and more security requirements, just as the problems faced by the IP network later, A simple owner-based ACL is insufficient to map all security control rules. The key to the problem is that the file system type and quantity caused by VFS are uncontrolled, while the UNIX File ACL is fixed. Therefore, another ing parallel to VFS is required, that is, the ing from another mechanism to a policy. If yes, I can call it VACL.
However, there is no VACL. Because the ACL is too coarse-grained, its semantics only applies to the file owner. It only says "yes or no" and cannot represent "yes, what must be done? "But later, something similar to the Beaufort tree classification, called" Capability ", that is to say, all the operations that can be thought of are represented by a binary bit, if an object has the permission for this operation, it is 1. Otherwise, it is 0, which produces a UNIX capability model, namely POSIX Cap. Everything looks perfect. However, unlike the later general classification index method that replaces the tree classification index method (in fact, people still advocate the tree model today !), POSIX Cap is not very useful. Procfs is also not suitable for managing security with Cap!
Procfs. The content of the file system is automatically generated. Each process has a directory in which attributes of the process exist. Let's ask who will define the Cap for operations on these files, if it is a system, how does the system know how to define a process when it is generated? If it is a user, a HOOK is undoubtedly added between fork/exec and procfs, this is too complicated. The original purpose of procfs is very simple. There are two types:
1. Export System Information
2. Export Process Information
In any case, the debugging function is enhanced. In any case, you cannot try to use procfs to do something against UNIX principles. The first problem is that the information exported by procfs includes the address space of the process. Isolating the process address space is the fundamental principle of UNIX and even all operating systems, as long as it is displayed in procfs, it may be read, write, mmap... many UNIX systems, including BSD, have gone through this process, so the later versions simply removed procfs. The second problem is that the kernel space should not process the information format, because VFS is hooked in the kernel state, operations on various actual file systems are also implemented in the kernel state, so there will be a lot of formatting operations in the kernel, however, the kernel should not do this. If binary data is exported directly, it violates the intention of procfs. Why did we leave the procfs class without fixing vulnerabilities and problems? This reflects the purity of UNIX design. On the contrary, it is the compromise of Linux.
There are a lot of debates around the retention of procfs, which are centered on two aspects:
1. class should be passed for procfs
Use the sysctl interface instead of procfs. Since the address space as part of the process property cannot be exported, why should we keep another 90% +?
2. procfs should be retained
Considering that sysctl is not a part of a standard tool set in every UNIX system, we recommend that you retain the procfs of the unified interface.
In any case, there is a debate over UNIX philosophy. Linux has completely put aside this and implemented its own procfs.
In the compromise of Linux, Linux does not abandon procfs, but fixes its key problems. As for other non-critical issues, the Linux community does not care. In the definition of the VFS operation set of procfs, Linux adopts the following definition:
# Define mem_write NULL # ifndef mem_write // a scary comment! /* This is a security hazard */static ssize_t mem_write (struct file * file, const char * buf ,... # endifstatic struct file_operations proc_mem_operations = {. llseek = mem_lseek, // There are many restrictions on the read operation, and access to the address space of other processes is not allowed. read = mem_read, // NULL defines the write operation. write = mem_write ,. open = mem_open, // No mmap Implementation };This avoids security issues!
Linux is moving further and further on the path where everything is file. Now you can see many unconventional FS, such as procfs, sysfs, devfs, debugfs, cpuset, cgroup, sockfs and so on... linux carefully manages all non-conventional file systems, including procfs, which can be read, which can be write, and what is strictly prohibited, I think this can only be done on an open development platform such as Linux. If you have any vulnerabilities, you can immediately find them and fix them as quickly as possible!