Re: Hurdish applications for persistence

[Marcus Brinkmann]

At Wed, 12 Oct 2005 21:21:24 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Thu, 2005-10-13 at 02:07 +0200, Marcus Brinkmann wrote:
> > > And I still consider chroot as a bad example, and consider sub-hurds
> > > (or some form of them) far more flexible than chroot().
> >
> > As said
> > previously, this is exactly what needs consideration.  It's not
> > something that can be invoked by a magic hand wave.  This "some form"
> > is not going to magically pops up into existance.  It requires careful
> > consideration and design, and, yes, some form of a working "chroot"
> > (which I will happily give it another name as to not confuse it with
> > the Unix chroot() call.  Let's say chr00t.).
> 
> Umm, guys? Chroot() was a late bolt-on to UNIX that attempted to provide
> a best-effort approximation to confinement in a system where it was way
> too late to do the real thing.

Ok, it's confusing to overload a term.  I tried to avoid that trap,
but it's difficult.

Here is what I mean: In your secure XMMS example, you said that you
should be able to pass a capability to the music directory of the user
to the player, and _only_ the music directory.

But in the Hurd, a directory capability allows you to look up the
special filename "..", and this gives you a capability to the parent
directory.  So, this can't be what you mean.

We need thus two types of directory capabilities.  One that allows
looking up "..", because that is still useful in many contexts.  And
one that is the "secure" version and disallows looking up "..".

In the Hurd, you can do this.  The way you do it is to set up a
"shadow root" for the directory capability.  If the shadow root is
set, then looking up ".." in that directory acts special.  There are
several options here, but one option is that the directory acts like a
root directory itself (this is the case if the shadow root is set to
the NULL capability).  Here is the interface:

/* Return a new file, NEW_FILE, with the same semantics as FILE, but
   with lookups of `..' (if FILE is a directory) redirected to PARENT.  */
routine file_reparent (
        file: file_t;
        RPT
        parent: mach_port_t;
        out new_file: mach_port_send_t);

Incidentially, this is how chroot() is implemented in the Hurd:

After appending "/." to the directory name to force correct error
handling, chroot() does this (note that _hurd_ports[INIT_PORT_CRDIR]
is the tasks root directory capability):

  /*  char *lookup = "path" + "/."  */
  file_t dir, root;
  error_t err;


  dir = __file_name_lookup (lookup, 0, 0);
  if (dir == MACH_PORT_NULL)
    return -1;

  /* Prevent going through DIR's ..  */
  err = __file_reparent (dir, MACH_PORT_NULL, &root);
  __mach_port_deallocate (__mach_task_self (), dir);
  if (err)
    return __hurd_fail (err);

  _hurd_port_set (&_hurd_ports[INIT_PORT_CRDIR], root);

It creates a new directory capability with the shadow root set to
NULL, then replaces the root directory capability with that (it also
does some other stuff, but that's beside the point).  This is why
chroot is allowed by any user of the system, not only root, in the
Hurd: It doesn't do anything but remove authority from the capability
you hold.

I think that this is a sane feature, and the implementation of the
shadow root functionality is not necessarily what has to be
criticized, IMO.  The problems lie elsewhere (ie, that the rest of the
Hurd system leaks capabilities).

I hope this makes it clearer.  How would you do it in the EROS filesystem?

Thanks,
Marcus