Thanks for the prompt replies; So let me get this right, if I hack an application (Capability A)and take over execution with my virus the kernel should be able to identify me as cap A. It should have list of my rights somewhere so I shouldn't be able to do any copying that I am not allowed to do by my kernel designated rights. However if I then create a new process with copying rights I can then get the system to copy my code with my newly created capability or are Rights recursive? So that a child process can have no more rights than than its parent?
Am I guessing correctly when I say that the kernel will ID a capability by its memory location? Is this how the kernel knows what is what? In that case what about RPC's? How can cross system procedure calls be securely identified? In Eros/Coyotos all processes are capabilities. Is this same understanding being applied to this project? >>2) How many capabilities can a capability have? >> >??? Do you mean - how many capabilities can a *process* have? A >process >can have any number of capabilities it gets/creats, untill it runs >out >of its capability-space. >??? Do you mean - how many *methods* can a capability have? It >depends >on the interface that capability implements. >I dont understand your question properly. >From what I have seemed to grasp a capability is an atomic unit of ability. Therefore it is system of controlling actions within a names-space. (I could be completely wrong, this is just what I have seemed to understand). Therefore a capability is an ID/Ability combination. All internal processing within the process can be seen in the normal method/attribute manner but any interaction with the system then needs to be looked at in the ID/Ability way. This would probably include all instantiations as they will each need there own ID/Ability pair. How can the system make sure that memory leakage is avoided? This is particularly important with a persistent operating system. I heard that the kernel should never be permitted to kill a process! Why not? Particularly if a process has gone out of control. Whats the thinking in that? In Eros/Coyotos all applications are limited to an application-user delimited name-space. If not a capability-user delimited name-space, an idea that I think is particularly good. What is the projects leanings towards this idea at current? A LOT of work has been going on within the project and I here that there are interesting ideas with regards to driver frameworks. Where can I get information on this? I think that the idea of establishing standards is the way to go, it will lead to longevity. On Sun, 2005-10-23 at 08:56 +0200, ness wrote: > [I answer the questions on my best knowledge, but that doesn't imply the > answers have to be right] > Justin Emmanuel wrote: > > I just have a few questions, sorry if these have been addressed already > > somewhere and I missed them, but I am curious. I have been listening to > > Dr Shapiro's talks on Eros and it made me ask some questions. > > > > 1) How can the a process/kernel know that a capability really is > > who/what it says it is? > > The kernel knows everything, so it has never a problem. > The second question is more tricky. In the Hurd, a process cannot know > that. It has to trust the soure of the capability. In EROS there is the > possibility to identify a capability. I'm not sure how it works, but it > has sth. to do with comparing caps, or so. We already had a discussion > about this here. > > > 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? 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? > > A capability points to one object and has some rights associated with it. > > > 3) Will L4 on Hurd be using a constructor capability? > > First, we're not sure anymore whether we'll be allowed to say Hurd/L4. > Maybye Hurd/Coyotos, maybye... Second, we had a lot of design changes > last time. Only a few people have an imagination of how the Hurd on X > will look like in the future. But I guess we will not adopt the > constructor mechanism. > > > 4) Does L4 have the answers to some of the questions raised by a project > > like Eros? > > The Hurd and EROS have different goals. The successor of EROS is coyotos. > > > > Thanks for you patience. > > _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
