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

[Ludovic Courtès]

Hi,

On Thu, Apr 27, 2006 at 03:12:17PM +0200, Marcus Brinkmann wrote:
> At Thu, 27 Apr 2006 14:59:26 +0200,
> Ludovic Courtès <address@hidden> wrote:
> > For small, specific interfaces, permission bits may even not be
> > needed at all most of the time: a capability to an object implementing a
> > small interface is already a very small, potentially "atomic" (i.e., no
> > further dividable) piece of authority.
> 
> You are right.  The pipe is a good example, again, because there
> really are only two pipe capabilities: the read end and the write end.

Indeed.

> For directories, it's a bit more complex, if we want to support
> restrictions like "transitive read-only" (all capabilities fetched
> through the directory are downgraded) and "opaque" (all _directory_
> capabilities fetched through the directory are downgraded to opaque,
> which implies read-only, but leaf nodes are not).  A directory may
> thus have "writable", "read-only", "transitive read-only" and
> "opaque", but they are all mutually exclusive (or rather: the latter
> two imply read-only, so there are really only 4 states).

I assume you're talking about "directories" within a file system, right?

I tend to think that Unixish and file-system-related object types are
not so good when reasoning about composition, capabilities, etc.
Some of these abstractions are too large, encompass various unrelated
concerns, etc.  Furthermore, they are not that crucial in a persistent
system.  ;-)

For instance, the file abstraction could certainly be separated into
various data types: currently, a file is a structure that associates
an octet stream with a name, various meta-data, a user ID, permission
bits, etc.  An "open file" (or "file handle") aggregates some more
information: offset, open mode, buffering type, etc.

Similarly, a non-file-system-style "directory" abstraction would just
bind names to directories or other arbitrary objects, not just files (the
current Hurd already permits that but the interfaces are still very
file-system-oriented).  Thus, "read-only" permission does not make much
sense in this context.  Read/write permissions just makes sense for "file"
objects.

Does it make some sense or am I just being too radical?  :-)

BTW, I only quickly browsed Mark Miller's thesis, but it seems that E
doesn't have "permission bits".  I guess "downgrading" would be
implemented by proxies in this case.  How about EROS?

> Some objects will probably not have any permissions at all, for
> example server "master" capabilities.

What do you call "master" capabilities?  Sorry if I missed the relevant
thread/wiki page.

Thanks,
Ludo'.