[Top][All Lists]

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

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

From: Marcus Brinkmann
Subject: Re: the deadly hypercube of death, or: handling permissions
Date: Thu, 27 Apr 2006 15:12:17 +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 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.


reply via email to

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