[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:24:49 +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 13:58:30 +0200,
Pierre THIERRY <address@hidden> wrote:
> I'm wondering if we couldn't see the permission problem in another way:
> why not have only types for separate permissions, and wrapper objects
> for composite?
>
> That is, for file, we would have the following types:
>
> IO FILE
> / \ |
> IO_R IO_W FILE_X
>
> For a binary that is both readable and executable, we would use a
> wrapper object that has IO_R and FILE_X capabilities.
I am not sure I understand. A File is always an IO object. The File
class is derived from the IO class. This is certainly something we
want to preserve.
However, more importantly, I don't know what you mean by wrapper
object. We want to limit ourselves to single inheritence.
> 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.
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 :)
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 <=
- 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, 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