l4-hurd
[Top][All Lists]
Advanced

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

Re: the deadly hypercube of death, or: handling permissions


From: Marcus Brinkmann
Subject: Re: the deadly hypercube of death, or: handling permissions
Date: Fri, 28 Apr 2006 00:47:45 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 27 Apr 2006 23:12:27 +0200,
Pierre THIERRY <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit Marcus Brinkmann dies 27/04/2006 hora 18:34:
> > Actually, it's only read and write.  Execution happens by reading the
> > file data and spawning a new process, completely in user space without
> > support from the filesystem.
> 
> Wouldn't it be possible to be able to execute a program without being
> able to read it?

Well, this depends.  In Unix, this is technically possible.  It is
also possible in EROS/Coyotos using the constructor mechanism, for
example.

However, I don't know any actual use cases of this pattern that I am
interested in supporting.  Quite the opposite: I find the use cases I
do know morally objectionable.

Your mileage may vary, but in the end this boils down to the DRM and
Trusted Computing discussion.  There are theoretical reasons for that,
but I can not expand on that right now.  In brief: to support this,
these programs would need to run on your resources, but without giving
you the authority to inspect and debug these resources.  This is the
key property that on the one hand is a hard requirement to support
this feature, but on the other hand violates the principles of user
freedom (as I define them).  I have an extensive argument for that,
but it is not yet ready for public review.

Thanks,
Marcus





reply via email to

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