[Top][All Lists]

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

Re: Server overriding; chroot

From: olafBuddenhagen
Subject: Re: Server overriding; chroot
Date: Thu, 27 Mar 2008 02:28:05 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)


On Wed, Mar 19, 2008 at 08:13:02PM +0100, Pierre THIERRY wrote:
> Scribit olafBuddenhagen@gmx.net dies 19/03/2008 hora 17:04:

> > The problem is that passive translators are started by the parent
> > filesystem server to which they are attached, not by the process
> > accessing the node; thus they get a "normal", non-chrooted port, and
> > consequently have access to the whole filesystem tree.
> The problem here is that authority is given instead of demonstrated.
> No translator should receive a port from a priviledged server like the
> parent FS server.

Sorry, that's too abstract for me...

> Would it be possible to somehow store a port or serialization thereof
> when setting up a passive translator?

It's not possible to do that directly. That was *precisely* what made
Marcus argue at some point that we need EROS-like persistence in the
Hurd -- see
http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00081.html . Note
however that in the meantime he changed his mind and realized that
EROS-like persistence isn't really the right thing for us...

In the Hurd, we don't have transparent persistence, which would allow
keeping ports (capabilities) directly between reboots. Rather, all
authority information is stored in the filesystem (mostly in the form of
UNIX file access bits -- but passive translators are also an important
element of it!); and the actual port relations are reconstructed from
that when the system comes up again. This is hard to get right (and as
you see we have issues with it), but not impossible -- note that at one
point Shapiro actually wanted to drop persistence from Coyotos...

, Marcus proposes a new method for implementing passive translators,
with the goal of addressing the chroot problem. While personally I
believe that the approach he describes doesn't really fundamentally
change what passive translators are and what they can do, some of the
changes he proposes should indeed help a lot in creating a secure


reply via email to

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