[cap-talk] MinorFS Philosophy
capibara at xs4all.nl
Mon Jul 28 03:35:49 CDT 2008
On Mon, July 28, 2008 06:21, Karp, Alan H wrote:
> Sorry for the delay in responding. I lost your note in a pile of unread
> Rob Meijer wrote:
>> 1) As a location where, if someone was to write a 'persistent' ocap
>> language, the process 'image' could be stored in a location only
>> accessible to the process that is to be the new incarnation of the
>> persistent process.
>> 2) A location where a program written in a language with serialization
>> support can put serialized parts of itself as a way to simulate 1.
>> 3) A private location for processes to store 'private' file system data
>> (dirs and files).
>> 4) Delegation of (decomposed,attenuated etc) access to 3.
>> 5) Making the receiving end of 4 persistent (composition).
> So, the answer is, it depends, which explains my confusion. I had been
> assuming your description of the original scenario included the mechanism.
> The thing missing was the step needed to preserve access across
> invocations in the absence of persistence.
> Now I have more questions. Except for #1, doesn't the right to access the
> file after restarting the program resides in the user's context?
The 'right' to access all the (relevant) MinorFs files and directories
resides with the userspace filesystem process MinorViewFs.
It is MinorViewFs its job to delegate the rights to subgraphs of the
There is a subgraph of the directory tree treegraph that you could say
represents the context for a particular user.
Lets call this subgraph the user context within MinorFs.
(MinorViewFs will delegate the this user context only to a special
administration tool run by the user, not to anything else).
A subgraph of the user context that MinorViewFs maintains is (in a
somewhat simplified view of reality) created for every distinct callchain,
thus 'init - kdeinit - konsole - bash - ssh' would get a different
than 'init - sshd - sshd - sshd - bash - ssh'. Lets call this subgraphs
the invokation-chain context.
A subgraph of the invokation-chain context is created in order to give
different processes with both the same uid and the same invocation chain
their own private 'slot'. Lets call these subgraphs the
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 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.
I like to think of user context versus pseudo persistent process context
as being conceptualy the same thing at a different granularity level as
process context and (programming language) object context.
In a regular program, you could say the private members of each object
reside in the programs process context, does that lose the advantage of
not having all the programs permissions in a single context as context
global mutable state?
If you are refering with your question to the availability of much of
/proc/$PID to anything running with the same uid, this is IMO a problem
that paralels that of using non memsafe programming languages. Using
MinorFs together with AppArmor can I feel remedy this problem in many
scenario's. What the limitations of these are is something I need to still
look closer at.
> With #1, how do you control that this user, and only this
> user, can start the incarnation of the new process without putting some
> permission in the user's context?
MinorViewFs uses callchain and user id to identify what subgraph to
delegate. The same program called by a different user or with a different
callchain will be interpreted as being a completely different pseudo
persistent process, and would thus get a different subgraph delegated.
As I don't completely seem to understand part of your questions, I hope
that if the above comes close to answering your question.
More information about the cap-talk