[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Translucency counterexample

From: Jonathan S. Shapiro
Subject: Re: Translucency counterexample
Date: Fri, 12 Jan 2007 09:28:06 -0500

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.

Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100

reply via email to

[Prev in Thread] Current Thread [Next in Thread]