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

[Marcus Brinkmann]

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