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

[Pierre THIERRY]

Scribit Marcus Brinkmann dies 26/04/2006 hora 21:12:
> To allow the full spectrum of flexibility, we should design our system
> to not rely on this minimal kernel feature we envisioned.

I agree, because it seems too mimimalist to be useful in the general
case. Additionnaly, it seems always preferable to me when a feature is
achieved with existing primitives instead of adding ones (which can tend
to bloated software).

> Summary: I have shown how permission bits with arbitrary semantic
> meaning can be integrated into an object type hierarchy that only
> supports single-inheritance, using the polycast operation.

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.

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.

I wonder if aggregating independent permissions doesn't even break POLA.

Then, it would be great to use Marcus' proposal for any set of
permissions that either have dependencies or are sometimes needed in
conjunction (like read/write if they are both needed for an opaque
PATT), but keep independent ones in separated types.

Separately,
Nowhere man
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature