l4-hurd
[Top][All Lists]
Advanced

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

Re: Directories traversal (was Re: the deadly hypercube of death, or: ha


From: Marcus Brinkmann
Subject: Re: Directories traversal (was Re: the deadly hypercube of death, or: handling permissions)
Date: Fri, 28 Apr 2006 00:54:30 +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 Fri, 28 Apr 2006 00:20:57 +0200,
Pierre THIERRY <address@hidden> wrote:
> After thinking on it for quite some time, there is something that I feel
> I don't understand fully: how would directories traversal work in a
> capability-based directory hierarchy (FS or not)? In fact, I think we
> need some additional permissions at the directory level:
> 
> If I have a lookup cap on a dir, I suspect i'll be able to know it's
> entries list and acquire a lookup cap on them.

Not necessarily.  The directories you can lookup have their own
permission bits, which are determined by the capability that was
actually linked into the directory.

> So if I have a lookup cap
> on the root of a filesystem, I seem to be able to read it's entirety. I
> think eiter I'm missing something, or there's a problem.

This will usually be the case, as it doesn't make sense to link
capabilities into a directory which you can't access :) However,
that's not quite as bad as you might think:

(1) The only components of the file system that are global are
    globally share static files, like system-provided software
    packages.  Each user has their own mutable file system, that can
    not be accessed by any other user (unless parts of it are
    explicitely shared).

(2) The only program that usually has access to your root directory is
    your shell (ie, your environment).  Applications only get access
    to selected files or subdirectories via the powerbox.

(3) You can introduce proxy-directory servers (or using the powerbox)
    that reduce permissions following arbitrary policies.

> I think we should have much more dir_t capabilities, that would express
> not only the permissions on the dir itself, but also what kind of
> permission we could gain for it's entries, if any.

This is what I described before with "transitive read-only" and
"opaque".  However, it is not clear if we really need them as
"first-class" permission bits.  These policies could also be
implemented by proxy-servers.
 
Thanks,
Marcus





reply via email to

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