[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 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
- the deadly hypercube of death, or: handling permissions, Marcus Brinkmann, 2006/04/26
- Re: the deadly hypercube of death, or: handling permissions, Ludovic Courtès, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Pierre THIERRY, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Marcus Brinkmann, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Pierre THIERRY, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions,
Marcus Brinkmann <=
- Re: the deadly hypercube of death, or: handling permissions, Jonathan S. Shapiro, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Pierre THIERRY, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Marcus Brinkmann, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Pierre THIERRY, 2006/04/27
- Re: the deadly hypercube of death, or: handling permissions, Marcus Brinkmann, 2006/04/27
- Execute without read (was Re: the deadly hypercube of death, or: handling permissions), Pierre THIERRY, 2006/04/27
- Re: Execute without read (was Re: the deadly hypercube of death, or: handling permissions), Marcus Brinkmann, 2006/04/27
- Design principles and ethics (was Re: Execute without read (was [...])), Pierre THIERRY, 2006/04/28
- Re: Design principles and ethics (was Re: Execute without read (was [...])), Bas Wijnen, 2006/04/28
- Re: Design principles and ethics (was Re: Execute without read (was [...])), Pierre THIERRY, 2006/04/28