At Mon, 01 May 2006 01:29:54 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > > Ok, that was not clear. The default libraries and services will make > > sure that the user does only execute programs from the user's own > > storage. > > This STILL doesn't address my example. I started the program, and I > handed you a descriptor that allows you to send IPC to my program. The > entire point is that I have *not* permitted you to instantiate it > directly or control its storage -- even if we have a "naked" storage > allocator. > > So the "naked allocator" restriction is not achieving the objective: the > user (in this case the recipient of the IPC capability) *still* cannot > examine the program they are executing. > > So next we must remove IPC, or if we do not, we should admit that this > is an impossible objective and stop compromising the system architecture > in order to achieve it.
Processes in general do not send random IPC to other processes. There is a narrow number of distinct cases where in my design processes send IPC to other processes, and I can justify each of them for my purpose. This is really not very different from EROS. As a very short summary, the list is: IPC to system services, IPC between cooperating processes (coordinated by a common parent), and communication between different users/groups. The latter class is the only one that requires special consideration. In this case, the communication must be tracable to a legitimizing user action. The reason you think that this does not achieve the objective must be that you have the wrong idea of what my objective is. We also have a different idea of what properties we want to protect and which violations consitute a compromise. I believe I could achieve all my functional objectives in the EROS/Coyotos system structure, although some things are made harder by it than I deem necessary (in particular issues related to virtualization of services). I can also achieve the same objectives in a much simpler system which has less code and less mechanisms. The things that you can do in EROS but which you can not do in my system are, at this point, simply not on my agenda. On the other hand, my system is much more protective of the user's freedom (to use, inspect, alter and copy data in the user's storage), and fits better with virtualization. This is admittedtly because it throws away those mechanisms which make virtualization hard. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
