On Sat, 2005-10-22 at 23:56 +0100, Justin Emmanuel wrote: > 2) How many capabilities can a capability have? E.G. A mouse pointer > capability loaded from a somewhere or other that also ( malevolently) > has the capability programed in to write to the hard drive?? Whats to > stop that happening?
I do not know how to answer the first part of your question, because it is unclear. I *think* the answer is: Every capability lets some set of operations be done on *one* object. A process can have as many capabilities (or as few) as it needs. Capabilities do not hold capabilities. The answer to the second part is: capabilities are kernel data structures in both L4.sec and EROS/Coyotos. They cannot be forged by applications. So either you *have* a capability to the hard drive or you do not. You cannot "invent" one. > Is the user requested to give permission every time > a particular I/O operation takes place? What if you have connected a > file system ( maybe a floppy, CD ROM) and wish to copy some directories, > will it ask for permission on every object? No. By connecting the directories, the user has already given the authority. No further questions are asked. The general rule in a capability system is: Authority grows from connectivity. The bad news is that users need to learn to be careful about what things they connect. The good news is that it is relatively easy to build user interfaces that help users make good decisions about this, and a lot of active and promising research about how, specifically, to do so is now going on. > 3) Will L4 on Hurd be using a constructor capability? I do not know. Unless L4.sec chooses to provide a COPY operation, the guarantees of the constructor seem impossible to achieve. > 4) Does L4 have the answers to some of the questions raised by a project > like Eros? I am not sure if you mean "EROS has identified some challenges, has L4.sec answered them?" or "EROS has some problems, does L4.sec improve on them?" In my opinion, L4.sec does answer many of the challenging problems that EROS identified. Not all of them, but many of them. This is not surprising -- many of the key ideas that differentiate L4.sec from L4 were adapted from EROS. I think that the reverse is also true. Several of the architectural changes in Coyotos come from adapting ideas in L4. I think when we discuss problems, we need to distinguish between issues of implementation (which can be fixed) and issues of architecture. Fixing an architecture problem creates compatibility issues. There are definitely some architectural warts in EROS. Some are corrected in Coyotos. I have looked at these warts for a very long time, and in every case I have reached the conclusion that the warts cannot, in principle, be eliminated. In each case I can see designs that would reduce some particular wart, but only with the cost that a different wart comes up someplace else in the architecture. My conclusion at this point is that the requirements for secure and robust designs cannot all be satisfied perfectly at the same time; you can only choose which warts are acceptable for your needs. I expect that the warts in L4.sec will be very different from the warts in Coyotos, but there *will* be warts. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
