[tahoe-dev] Cleanest way to use Tahoe and MinorFs together?

[Rob Meijer]

On Tue, July 22, 2008 02:37, zooko wrote:
> Dear Rob Meijer:
>
> I'm sorry I haven't replied to your queries sooner about how to use
> Tahoe and MinorFS together.  The reason is that I don't really
> understand MinorFS well enough to answer.
>
> I read this entire thread on cap-talk with interest:
>
> "[cap-talk] MinorFS Philosophy"
> http://www.eros-os.org/pipermail/cap-talk/2008-July/011100.html
>
> and I thought it was good that you were exploring the idea of having
> a component which is directly controlled by the user (e.g. a unix
> shell connected to a tty, or a GUI that the user is interacting with
> directly) but which is, as you put it "somewhere halfway in the
> delegation chain".
>
> It sounds intuitively like a good idea, or at least one that ought to
> be explored in contrast with the Powerbox idea, where the user has
> direct interactive control of the component (the Powerbox) which has
> all the authority.
>
> However, I don't really understand how a person would use MinorFS.  I
> gather that it is a FUSE plugin, but I would have to read the
> documents and experiment with it before I even started to form ideas
> about how MinorFS and Tahoe could both be used by the same users.

There are two important differences between Tahoe and MinorFs.
Tahoe works within a broad networked scope, and with a granularity of
'users'. MinorFs works in a local machine scope, but (with a litle help
from AppArmor) with a granularity of 'pseudo persistent processes'.
I feel that combining the two, or copying some code from MinorViewFs to
Tahoe, might make it possible to achieve the granularity level of MinorFs
with the networked scope of Tahoe.

To ilustrate what I mean, let me expand on Aleksandr's comment that he
does not feel he needs a system that protects him from himself.
This remarks seems to stam from the line of thinking that each process
running with a user his uid is always doing what the user intedns it to
do.

If one would be using a word processor as main application to work on data
stored with Tahoe, and never ones mail client or webbrowser, than there
would according to POLA at the process level be no need for the webbrowser
and mail client to have the knowlege of the caps needed to access the
data.

MinorViewFs maintains symbolic links that point to (initialy) process
private directory caps within MinorCapFs. A quick way to couple this with
Tahoe might be to replace MinorCapFs with a Tahoe fuse filesystem, but
this would I feel very likely  not be the cleanest way to do this.


Rob