[tahoe-dev] tahoe now has an FTP server!

Brian Warner warner-tahoe at allmydata.com
Thu Nov 27 00:10:32 UTC 2008


On Mon, 24 Nov 2008 09:37:02 -0800
Nathan <nejucomo at gmail.com> wrote:

> This feature is the first instance (aside from the commercial
> AllMyData service) I am aware of that maps a concept of "user account"
> to Tahoe's cap design.
> 
> I have some questions:
> 
> Can I enable anonymous ftp access?

In principle, yes.. Twisted's FTP server support has provisions for anonymous
access. There's nothing in Tahoe's code to turn it on though.

> If I did, would the result differ much from the WUI interface in its
> security model?

Well, assuming that you didn't create some sort of catch-all "public"
directory for all anonymous users to use, the only thing an anonftp user
could do is cd to a magic /uri/DIRCAP directory (not unlike the "visit a file
or directory by uri" box on the WUI's welcome page). Once there, they could
examine files as they please, and (if the cap is RW) upload files or make new
subdirectories.

The "user account" is really just an alias for an initial directory.

> Specifically for browsers:
> Can browsers do anything other than ftp retrieval?  Can they list
> directories?  If they retrieve html, do they render it?  If it
> renders, is its domain the host, port pair of the server?

If I remember correctly, browsers are basically read-only, and list
directories just like apache would render a server-side directory without an
index file. It looks Firefox 3 thinks it can speak FTP (it asks me for a
password at the right time), but doesn't seem to render anything.. dunno if
this is a problem on the firefox side, or something lacking in tahoe's FTP
support.

I suspect the browser would indeed render HTML. Once upon a time, back in the
days before Apache, folks would serve HTML through an FTP server. I wouldn't
be surprised if the host+port pair got used as a "same origin policy" -type
domain, possibly with the username mixed in. But I haven't tried any of
these.

It goes without saying that if you care about the confidentiality of your
data or the integrity of your account, you won't access it over FTP, because
everything is unencrypted. The only way I could recommend using tahoe's FTP
server is via localhost.

> Do tahoe devs envision deploying this username/password access scheme
> elsewhere?  (For instance, optionally in the WUI?)

Eh, maybe. As you know, I'm a fan of the capabilities model, and adding a
username/password scheme would tend to obscure the underlying security model.
So I'm not inclined to add anything to Tahoe beyond what's necessary for the
allmydata business model.

The main issue is: who gets to see your dircaps? If the WUI acquires this
sort of thing, that means both Alice and Bob may be using some webapi node to
access their files, and that webapi node now gets to see both of their
dircaps. In addition, it means that Alice and Bob don't remember their own
dircaps, but instead they rely upon some external login service to remember
them, which means the login service also gets to see their data.

To remain safe from this sort of eavesdropping, I encourage Tahoe users to
run their own node, and to manage their own root dircaps. If you're doing
that, then the "login" phase is just extra noise.


cheers,
 -Brian



More information about the tahoe-dev mailing list