[Top][All Lists]

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

Re: HURDNG : Which type of OS design could we have to think nowadays ?

From: Marcus Brinkmann
Subject: Re: HURDNG : Which type of OS design could we have to think nowadays ?
Date: Tue, 08 Aug 2006 08:21:01 +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 Tue, 08 Aug 2006 00:28:33 +0200,
"Ernst Rohlicek jun." <address@hidden> wrote:
> Persistence: Well, I'm not sure whether orthogonal persistence (in my 
> interpretation this is quite similar to hiberation / suspend to disk) is 
> really required - better: what it's benefits in a general-purpose OS for 
> non-embedded CPUs are...
> After all you can still store your caps on disk, if you would like to.

You can, but if you do not save all the state, but only part of it,
you face the non-trivial question which state to save and how to
reconstruct the state that you don't safe (if it needs to be
reconstructed).  Clearly most of the state in your machine at any
given time is junk.  If you tell me which 90% of it is junk, I'd be
very happy to drop the rest.

So, to answer this question, we need to look at all the state and need
to be able to label it with "save this" or "don't save this".

Case in point: The Hurd passive translators are supposed to capture
the state of a server in a command line string associated with an
inode (the "name server entry" if you want).  But in the current
implementation, this fails to capture the complete state of the server
process.  This allows for rather simple attacks to escape a chroot
environment, for example (because the filesystem jail of the server
process is not captured state), and the system will reconstitute it
with the wrong value).

Of course, in the current implementation, we do not have any feature
to save capabilities to disk at all.  Capabilities are reconstructed
from the user ID using the auth server (the filesystem stores user IDs
with inodes to control privilege to reconstitute capabilities).  This
gives us the problems associated with ACLs.

But being able to store capabilities is just a technical requirement
for a solution, not the solution itself.  The real problem lies in
identifying the state that needs to be captured, not how to capture it
technically.  It's semantics, not syntax.

I am not saying it's an impossible problem.  It doesn't need to be.
But it is not clear to me which solution is actually simpler.  May
depend on other parts of the design (features, etc).


reply via email to

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