l4-hurd
[Top][All Lists]
Advanced

[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 14:58:29 +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:42:41 +0200,
Pierre THIERRY <address@hidden> wrote:
> 
> Scribit Marcus Brinkmann dies 27/04/2006 hora 14:24:
> > However, more importantly, I don't know what you mean by wrapper
> > object.  We want to limit ourselves to single inheritence.
> 
> I think I was thinking to something that cannot be achieved with single
> inheritance, in fact... That is, an object that could mutate its
> interface to add (or remove) methods when it is brougth the associated
> capabilities. I think this isn't possible in Coyotos, is it?

In fact, this is how permissions are implemented.  We create one
wrapper object for each object+permission bit combination.

From the protected payload in the wrapper object, we determine the
object ID and the permission bits.

> > 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.
> 
> I'm not sure. How many times in a classical software are you needing two
> or more access modes to something? Saving a file ony needs write access.
> Opening only needs read, and maybe probing that write is possible
> (because the user could arguably want to save the modifications made
> later). Launching an application only needs execution. And so on.
> 
> Debugging would probably need both read and execution. Do you see other
> cases?
> 
> In fact, that would just make cleaner programming easier.
> 
> > Delegation would then be simple of course: You just select the desired
> > capabilties from the set.
> 
> That's one obvious benefit, yes.
> 
> > I have considered that before, storing a read and/or write capability
> > in each directory slot.
> > 
> > It's worth thinking about, if only to see what can break :)
> 
> I'm not sure anything breaks, so let's try to find something.

Well, say you have two capabilities per file in a directory, one for
read and one for write access.  Then over time, due to bugs or other
misbehaviours, they could become out of sync: They could refer to
totally different objects.  But everybody will assume they will refer
to the same object.  So, we are introducing a new class of possible
bugs.

I agree with you that one would have to look carefully at the possible
use cases.

Thanks,
Marcus





reply via email to

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