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: Pierre THIERRY
Subject: Re: the deadly hypercube of death, or: handling permissions
Date: Thu, 27 Apr 2006 14:42:41 +0200
User-agent: Mutt/1.5.11+cvs20060403

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?

It would still be possible with a dir object, from which one acquire the
specific capabilities, but this is maybe far too overhead, and
manipulating individual capabilities is maybe easier (or maybe not).

> 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.

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

Attachment: signature.asc
Description: Digital signature


reply via email to

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