On Fri, 2007-01-12 at 12:22 +0300, Anton Tagunov wrote: > Doesn't existence of process type system > preclude "field replaceability"?
It depends what you mean. If you mean "can a third party replace a component undetected?" the answer is "not if the caller checks". If you mean "can a vendor provide an upgraded version?" the answer is that (a) the installer could provide for this, but (b) it doesn't. In practice, what happens is this: There is a namespace (a directory) of constructors that is made available to all shells. All constructors in this directory have confined yields. Only the installer can write this directory. The user's shell instantiates the program by invoking the appropriate constructor. At this point no authentication is needed, because you are invoking the constructor directly. So the cases that concern us are (a) lateral authentication -- which again relies on using the constructor from the directory, so no problem there because the constructor is going to be replaced, or (b) internal upgrade within an application. This is probably something that wants to be handled through other mechanisms. In practice, most uses of the identify operation are for validating things like password subsystem instances in lateral tranfers. shap -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
