[tahoe-dev] question about sharing...

[Zooko O'Whielacronx]

On Wed, Jun 1, 2011 at 11:42 AM, toby cabot <toby at caboteria.org> wrote:
>
> I'm starting to play around with Tahoe-LAFS and it looks very
> interesting.  The quickstart instructions and public storage grid make
> it quick and easy to get going.  Thanks!

I'm delighted to hear this! Please let us know if there's more we can
do to make it easy for people to experiment with Tahoe-LAFS.


> I have a question about sharing files with other people and I can't
> find the answer on the site but I hope this isn't a FAQ.

We should write a FAQ about this! But the answer might be long. Might
need to be its own wiki page. Any volunteers?


>   If I run my
> own client with the web user interface, I imagine that I can share
> files by simply giving someone a directory URL.  Could they then give
> this URL to someone else, perhaps someone that I wouldn't want to see
> the directory?  Is there an authentication component that I'm missing?

Yes they could. There is no other authentication component built into
Tahoe-LAFS at this time.


> If I give someone a URL to a directory can I later revoke that URL
> somehow but still be able to access the directory myself?

This totally depends on how you are sharing. In terms of the
"Tahoe-LAFS network topology" graph --

http://tahoe-lafs.org/~zooko/network-and-reliance-topology.png

-- you can share with someone else either by letting them connect to
your Tahoe-LAFS gateway with an HTTP client or by letting them connect
to the storage servers with a Tahoe-LAFS gateway. The former has more
or less the same access control properties as any HTTP server. The
latter's access control policies are further constrained by the fact
that the user doesn't have to go through your gateway.

If you let them connect to your Tahoe-LAFS gateway with an HTTP client
then you can enforce whatever access control policies you like, just
as with any other HTTP server. They are completely vulnerable to your
HTTP-server/Tahoe-LAFS-gateway for availability (whether they get the
file or not when they request it), as well as for confidentiality
(your HTTP server can read the contents of any file they request), as
well as for integrity (your HTTP server can change the contents of any
file they request before they see the file).

This is the approach that I was suggesting to Brandon Meskimen in my
recent post: [1].

If you let them connect to the storage servers with their own
Tahoe-LAFS gateway, then you can't use your control over the gateway
to enforce your own access control policies. There are advantages to
this—you eliminate a Single Point of Failure in your system and the
end user can verify the confidentiality and integrity of the data
directly by relying on their own Tahoe-LAFS gateway.


What do you think? Let's talk about this more. I'm fairly proud of the
access control scheme that Tahoe-LAFS already offers (which is
summarized in [2] and detailed in [3]). I think it is a powerful and
flexible architecture to build on top of. But I'm sure that it can be
improved, both by building more apps on top of it and by extending the
behavior of Tahoe-LAFS itself (#152, #795, #954, #958).

Feedback from real users about what they want, and more importantly
what the experience when they *try* it, is extremely valuable for this
project.

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/152# build "sharing
slots" / use mutable files as primitives for sharing messages
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/795# append-only files
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/954# revoke write authority
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/958# LAFS 301 Moved Permanently

[1] http://tahoe-lafs.org/pipermail/tahoe-dev/2011-June/006394.html
[2] http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst#access-control
[3] http://tahoe-lafs.org/trac/tahoe-lafs/wiki/Capabilities