5. The second example in Section 16.2 asserts that UNIX file descriptors are in fact capabilities. Please explain in detail why this is true. (Hint: How are file descriptors used?)

EXAMPLE: To open a UNIX file, a process gives the file name to the kernel. The kernel obtains the files inode number by resolving the name through the file hierarchy. Once the inode is obtained, the system determines if the requested access should be granted using the access control permissions. If the access is granted, the operating system returns a capability called a file descriptor. The capability is tightly bound to the file object, so even if the file is deleted and a new file with the same name is created, the file descriptor still refers to the previous file.

The codewords of Iliffe [943] are similar to capabilities. Dennis and Van Horn [552] first suggested capabilities as a way to control access to objects in memory or secondary storage. Fabry generalized this idea to implement capability-based addressing [647].

The architecture of capabilities is more interesting than that of access control lists. The access control list and the process identity are under the control of the operating system. In the absence of flaws, user processes can change them only by invoking the operating system services. However, a process must identify a capability in order to use it, so the process must have some control over the capabilities. If the process can forge a capability and then use it, access controls fail.

Answer: