|Subject:||Re: Codezero v0.2 Capabilities|
|Date:||Mon, 07 Dec 2009 21:09:50 +0100|
|User-agent:||Mozilla-Thunderbird 18.104.22.168 (X11/20090103)|
Bahadir Balban wrote:
When it comes to making the ipc call though, you don't pass the capability id to the call. You pass the thread id you want to ipc to. The system call signature is the same as if capabilities were not there at all. But it surely gets checked, the relevant capability is found, it's resource id is matched with the passed thread id, and resolved.
How does capability transfer work in your system? As far as I know, one important feature of capabilities is that they unify authorization and designation.
Moreover, this breaks (at the kernel boundary!) one important design principle (which I value): explicit designation of authority. How can your system avoid the confused deputy problem?
The reason I did it this way is that, when I wanted to do ipc, it feels natural to pass the thread id. You might argue that the capability id could have been the same as the thread id, well in this way I managed to differentiate concepts from each other, and it felt that a user of the interface also benefits by not having to know about capabilities at all (provided that they're initially configured correctly of course).
I also think this is the more natural thing. But see my above comment on why I think it is the wrong *fundamental* abstraction.
|[Prev in Thread]||Current Thread||[Next in Thread]|