Scribit Marcus Brinkmann dies 06/01/2007 hora 09:26: > If the power relationship between the two actors is rightfully total > dominance, I have no principled objection. If the power relationship > between the two actors is rightfully a sibling relationship, I do.
I quite don't see the principle that should lead to that distinction. I don't see why processes could not do what we can do on an everyday basis, that is give the /usus/ of an object to another process, while keeping the /abusus/. Occasionnally, my mother permits me to use her car, and while doing so, she has fully the right to reclaim it at any moment, and I have the duty to have the car remain in the state I was given it. This kind of interaction is just made infinitely more secure between processes as a process cannot alter the usability of a memory page or of some CPU time. > If you think that this means I could accept the EROS space bank design > if it is only used in relationships where one actor totally dominates > another, then you are approximately correct, however, I would also > inspect other mechanisms as well that may achieve the same or > something similar. But then you would place a totally useless and arbitrary limit: a feature would be present in the code of the Hurd and you would deny anything but the TCB to use it, without any technical reason. While it may be totally right to do so, and I completely understand that you want to stick to some principles with the design of the Hurd, that seems very strange to me. The question also is: if using this feature system-wide without restriction enables users to have a more secure system, what would stop them to use a modified Hurd to do so? You may also be right that people thinking that the scheme I describe is highly desirable could probably contribute to the Coyotos OS instead of Hurd. If Hurd becomes a very usable OS, it would a shame if the limitation you plan to include in your design leads to a fork. Quickly, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
