[cap-talk] MinorFS Philosophy

Rob Meijer capibara at xs4all.nl
Tue Jul 29 09:17:41 CDT 2008


On Tue, July 29, 2008 00:51, Karp, Alan H wrote:
> Rob Meijer wrote:
>>
>> > Doesn't
>> > that lose the advantage of not having all the user's permissions in a
>> > single context?
>>
>> I don't quite understand what you mean by this.
>
> In an earlier note, you commented that concentrating all the user's rights
> in a powerbox was something you avoided by having the program own the
> right and delegate to the user, rather than the other way around.  That
> sounds like a good thing, but I'm having trouble understanding how it
> works across restarts.
>>
>> What MinorViewFs does is that it delegates the right to the pseudo
>> persistent process context to the active process that it views as an
>> incarnation of the identified pseudo persistent process. It does this
>> by
>> means of puting a symbolic link /mnt/minorfs/priv/home that points to
>> the
>> relevant subgraph under /mnt/minorfs/cap/<DIR_NODE_PASSWORD_CAP>/ .
>> For each distinct combination of user id, callchain and slot,
>> <DIR_NODE_PASSWORD_CAP> would point at a different subgraph, thus
>> ensuring
>> the (initialy) private view.
>>
> That's the part I don't understand.  Can you be more specific, showing an
> example with a user Alice and a program Edit?  Your description makes it
> sound like Alice's home directory has links to all her capabilities, which
> seems to me to be a powerbox.

Ok' I'll try to clarify, let me first try to seperate the 'what' from the
'how' as that may possibly help in reasoning about the differences.

If you try to translate the regular home dir, the  powerbox approach and
my approach to the same concepts at a program/classes scope/granularity, I
feel the representation would roughly be something like:

1: regular home dir
  class AliceScope: public UserScope {
    public:
     static DirTreeNode *globalHome;
     class EditorProcess: public Process {
        ..
     }
     class MailClientProcess: public Process {
        ..
     }
  }

2: powerbox
  class AliceScope: public UserScope {
    public:
     class PowerBox {
       private:
        static DirTreeNode *globalHome;
       ..
     }
     class EditorProcess: public Process {
        ..
     }
     class MailClientProcess: public Process {
        ..
     }
  }
3: private storage.
  class AliceScope: public UserScope {
    public:
     class EditorProcess: public Process {
       private:
        DirTreeNode *mPrivateHome;
        ..
     }
     class MailClientProcess: public Process {
       private:
        DirTreeNode *mPrivateHome;
        ..
     }
  }

If you keep the above simplified translation in mind, it might be simpler
to follow 'what' I am trying to do, and separate it from the 'how'. You
could say the goal of the /mnt/minorfs/priv/home symlink is the same as
the mPrivatehome member pointer, to point to a 'private' DirTreeNode.

So lets take this to your example, and at the 'how'.

If the program 'Editor' is started by the 'Shell', that again was started
by the 'Init' process, and Editor runs with the user id of the user Alice,
we could say the Editor process is an instance of
'Alice at Init-Shell-Editor'.
If at startup, the editor is the first and only instance of
Alice at Init-Shell-Editor, we could assign an identity to the process that
identifies the process is occupying the first slot. If a second instance
is started by the shell and runs (initially) in parallel to the first, the
second editor could get the second slot. If the first instance is stopped,
and an other editor instance is started, than the first slot will be free.

The two running instances of the Editor could thus be seen to hold the
identities, where each identity can be mapped to a process private
'persistent' directory:

  Alice at Init-Shell-Editor:0   -> /var/minorfs/data/Alice/Init-Shell-Editor/0
  Alice at Init-Shell-Editor:1   -> /var/minorfs/data/Alice/Init-Shell-Editor/1

How MinorFs implements this is that MinorCapFs masks the 'real'
directories after password capability style strong paths, while
MinorViewFs takes care of identifying the pseudo persistent process and
providing the symlink:

Thus for Alice at Init-Shell-Editor:0 this may be:

  /mnt/minorfs/priv/home  ->
        /mnt/minorfs/cap/586026bc7cd37de3049711cddc2d60a0824dd3bd/


While for Alice at Init-Shell-Editor:1 the link may be:

  /mnt/minorfs/priv/home  ->
        /mnt/minorfs/cap/ea15381ebe3318269ec1ae3ac222b4b9db9d42d0/


If the first editor writes data to /mnt/minorfs/priv/home/resume.txt, it
will end up in  /var/minorfs/data/Alice/Init-Shell-Editor/0/resume.txt
that is globally accessible as 
/mnt/minorfs/cap/586026bc7cd37de3049711cddc2d60a0824dd3bd/resume.txt to
anyone with knowledge of the last path. It would however not be conform
POLA for the Editor to delegate the
586026bc7cd37de3049711cddc2d60a0824dd3bd token. To accommodate for this,
MinorCapFs allows for the editor to fetch
the extended attribute 'cap' of the resume.txt file, resulting in a
different strong path token that allows access only to the resume.txt file
without disclosing access to /var/minorfs/data/Alice/Init-Shell-Editor/0.

The editor does thus not have to ask a powerbox for a part of the static
global home treegraph to be delegated to it, instead it can store the
resume.txt in its own private home storage space, and delegate the resume
file to the user, or any program that it can communicate with.
The receiving program also has its own private home storage, that it can
use to create a symlink to the delegated resume.txt file, in order to also
make the delegation persistent.

Rob




More information about the cap-talk mailing list