At Thu, 27 Apr 2006 13:58:30 +0200, Pierre THIERRY <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
