|
|
|
|
|
by szc
2269 days ago
|
|
There are some real issues with implementing revokable capabilities on UNIX and Unix Like operating systems. For example, access to a file. Lets say you have a capability that grants file access. One can open the file and read and write to it when you have the capability. The file descriptor can be made to refuse access when the capability is revoked -- cutting off reads and writes, you'll really need a new error code for this as no others really explain what happened. However, this isn't enough, on UNIX systems that support mmap() your "access" capability now needs to be intertwined into the paging system, every page or mapping now has to be capability marked and checked. Paging is asynchronous, what happens when the capability is revoked? Is there now a hole in the address space of the process? How on earth do you communicate that to a process that might have pointer references into the mapped data? Which software programming language could support this? What happens when the process if forked? Does this duplicate the capability or not? Similar problems exist with shared memory and semaphores -- revoking an associated capability could deadlock a system. In my opinion, in order to make a system useable, a programmer or user must be able to build a mental model of how things work. Capabilities and resources suddenly disappearing is a challenging environment to work in. Just look at all the issues / problems that plague pluggable devices. |
|