[cap-talk] MinorFS Philosophy

Rob Meijer capibara at xs4all.nl
Sun Jul 13 03:34:08 CDT 2008

On Sun, July 13, 2008 07:23, Karp, Alan H wrote:
> Rob Meijer wrote:
>> And just as with active objects, giving a user only the authority he
>> needs at the time
>> he needs it to get his job done should IMO make his job much more simple
>> and thus more
>> manageable.
> I've been following the discussion but not commenting because something
> that I couldn't identify bothered me.  I now know what that is.  What is
> the "user" in the above?  I've been using the term to mean the person and
> the totality of the permissions that person can use.  These permissions
> are usually held by a process that is sometimes called the powerbox.  The
> user expresses what is to be done by telling the powerbox to start a
> process with a subset of those permissions.
> You are saying something different, but I don't understand how that works.
>  Say the user is doing one task with the least set of rights needed for
> that job and wishes to start another task that needs a different set of
> rights.  How does the "user" get the authority needed to do the second
> task?

Let me try to explain what I am trying to say by giving an example.
Lets say  user U is reading his mail using a mail client M , receives a
pdf attachment F that she wants to view with pdf reader P.
We will end up with two scenarios:

1) * U asks M to delegate F
   * U asks a powerbox B for a file handle.
   * B asks U to designates a location for F in its user global
     file system namespace.
   * U designates the location.
   * B opens a new file and delegates this to M.
   * M creates F.
   * U asks P to open a new file to view.
   * P asks B for a read only file handle.
   * B asks U to designate the file F in its user global file
     system namespace.
   * U designates the location.
   * B opens the file read only and delegates it to P.
   * P reads F ans renders it.

2) * U asks M to delegate F.
   * M creates F in its own enviroment and delegates a read only
     capability to it to U, and keeps it in its controll for later usage.
   * U (optionaly attenuated) re-delegates the received capability to P.
   * P opens F and renders it.

I not sure I got the powerbox completely right, but  the main difference
in my view is the need to put and maintain files in a user global
filesystem namespace. If you were to put it into programming terms, the
uid bound $HOME managed by though the powerbox by the user would in my
view be as one big set of global variables that in the end one entity, the
user, has to manage.
The persistent  process bound $HOME would however be equivalent to private
object members that are encapsulated by a relatively small amount of
programming logic.

The user may want to put some delegated capabilities into a single managed
namespace for convenience, but this namespace would not include dirs and
files that in OO programming would be completely hidden also from the
For example the internal database files used by the mail client to store
mailboxes should not have to be managed by the user. The user doing non
admin tasks has no need for any authority to files like these.

In the second scenario th user becomes a broker of sort, not a manager af
all applications their private data that happen to be stored in a global
user owned namespace.

Is this making sense Alan, or am I missing some essential point here?


More information about the cap-talk mailing list