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

[Marcus Brinkmann]

At Thu, 27 Apr 2006 16:24:01 +0200,
Ludovic Courtès <address@hidden> wrote:
> > 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.


A directory has lookup, which would require read capabilities, and
link, which would require write capabilities.  I think it is useful to
give some programs only lookup/read access to a directory and not
link/write access.

> > 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.

Currently, the file server "master" capability supports one call
(beside the usual ones): files_create_file.  Ie, it is what allows you
to create new file objects.

Similar for directory server, pipe server, etc.

Thanks,
Marcus