OK got that, thanks. This clears up a few of the misunderstandings that I had with the last email. Still trying to get my head around capabilities.
"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." On Sun, 2005-10-23 at 13:54 -0400, Jonathan S. Shapiro wrote: > 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
