[Top][All Lists]

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

Re: Part 2: System Structure

From: Michal Suchanek
Subject: Re: Part 2: System Structure
Date: Wed, 24 May 2006 15:24:33 +0200

On 5/24/06, Marcus Brinkmann <address@hidden> wrote:
At Tue, 23 May 2006 12:13:17 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> So: eliminating DRM does not require eliminating constructors. A
> translucent space bank design is entirely sufficient. All of the rest of
> the properties that you are worried to avoid are a consequence of
> opacity. [It is possible that I have failed to consider something, but I
> am fairly confident about this statement technically.]

Although this is true, I always found the constructor quite an "in the
way of doing things" mechanism, unrelated to the DRM discussion.  The
reason is that the process composition happens too early for my taste.

You believe firmly that the constructed program embodies the
programmer's will, and you rely on this for various security
arguments.  This is why the constructor mechanism is designed around
the assumption that constructing the process is a separate operation
from running an instance of the process.  So, in the constructor
model, first all things are done to prepare a process image, or at
least to allow the process to prepare its own image, then the
requestor of the constructor instantiates it.

However, I believe that there are many good and interesting
applications where the instantiation operation influences heavily the
process composition operation.  For example, in Unix, shared libraries
are frequently replaced dynamically with LD_LIBRARY_PRELOAD or
LD_LIBRARY_PATH, not only in development, to achieve various goals.
Programs are run in specially prepared sessions, like ltrace, strace
(Unix), rpctrace (Hurd), fakeroot, to observe or control their
behaviour.  In the end, I want to make all types of virtualization and
debugging very easy.  The constructor sometimes makes them harder, by
putting a piece of infrastructure in the way of achieving these goals.

There see no reason why constructors would get in the way of such
tools. You sould be able to trace the capabilities you give. In the
cases the constructor gives a special capability you can still trace
how the capabilities you gave are used.
Admittedly you would have to create a new constructor for changing
libraries or tracing the capability inserted into the constructor. If
you have access to the capability yo can do so. If the constructor was
set up by an administrator or another user to perform some service you
cannot trace all aspects of the program because you should not get
direct access to the capability embedded in the constructor. That
sounds reasonable to me.
And I do not see why LD_LIBRARY_PATH should be so much of an issue.
Since the system allows confinement we should use the feature, and
implement most functionality as separate processes rather than

I learned from you that when you find you keep fixing a design, it
probably is the wrong design to begin with.  There have been many
proposals to fix the space bank + constructor design to allow it to
support virtualization and debugging.  I think I do understand how,
technically, I can recover my system design from the constructor
mechanism by a couple of extensions.  However, if the constructor
stands in the way of all the things I want to do, it seems opportune
to ask why it should remain central to the design.

It depends. If it is a simpe change that allows us to get the system
we want I would not object against that. If it means fixups all over
the system it is obviously wrong.
However, it is not yet completely clear what system we want. So it is
not obvious which way it turns out.



reply via email to

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