Re: Translucency counterexample

[Jonathan S. Shapiro]

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