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

[Marcus Brinkmann]

At Thu, 27 Apr 2006 14:59:26 +0200,
Ludovic Courtès <address@hidden> wrote:
> 
> Hi,
> 
> On Thu, Apr 27, 2006 at 02:24:49PM +0200, Marcus Brinkmann wrote:
> > At Thu, 27 Apr 2006 13:58:30 +0200,
> > Pierre THIERRY <address@hidden> wrote:
> > > Something should also be considered: is it always needed or desirable to
> > > have many independent permissions associated with one capability? I
> > > mean, if execution permission has no relation with read/write
> > > permission, there is no need for a capacity that could designate both.
> > > If I want to execute a file, I invoke the execution cap. If I want to
> > > read it, I invoke the read cap.
> > 
> > This works, but could easily result in a management nightmare.  You
> > would have to keep track of up to N capabilities for each "actual"
> > capability you are interested in.  Delegation would then be simple of
> > course: You just select the desired capabilties from the set.
> 
> In practice, there should not exist a zillion of permission types for a given
> interface.  Otherwise, that might mean that the interface is just too
> large.
> 
> 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.

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

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

I think the directory server illustrates that with more complex
interdependencies, you can not really do it like Pierre suggests,
because the permission flags are not independent.

Thanks,
Marcus