[tahoe-dev] How should extensions provide cap management user interfaces?

[Brian Warner]

> If the alias scheme becomes the status quo, how does that affect the
> user interaction trade-offs?  If it becomes status quo, would it make
> sense to move it into the wapi layer?  If not, why not, if all
> extensions use that scheme already?

The reason that these aliases are not moved into the web-API layer is that
they are guessable. The tahoe webserver, even if it's only listening on the
loopback interface, is still pretty easy for an attacker to get to (CSRF
attacks, the most basic of which is to put a form on their own page that
points to a POST URL on your tahoe node). So we can't afford to give any
authority to an arbitrary web client: they must demonstrate their authority
by providing the file- or directory- cap URI.

(We used to have URLs like "http://127.0.0.1:8123/private/subdir/foo.txt",
corresponding to a CLI command like "tahoe get tahoe:subdir/foo.txt", but we
removed it because it would give web-based attackers the ability to upload or
delete files in your private directories).

The CLI tools are not subject to this limitation, because their authority
comes from the invoker's ability to read from ~/.tahoe . Web clients (who
only speak over HTTP) do not get to do this.


I prefer the idea of each tool being configured (at mount time, in the case
of a FUSE frontend) with a directory-cap. The only time it is appropriate to
make it easier than that is if the tool is already associated with a
filesystem (i.e. the tools is launched by the same user who can read from
~/.tahoe/aliases), in which case we can grant the tool the same authority as
the user. In this case, the tool can be configured with an alias name instead
of a raw dircap.

I think browser bookmarks should remain private to the browser, but other
tools could accept a web-api URL as a configuration parameter: the tool can
simply parse out the dircap from inside the URL.


> Currently the fuse_a implementation mounts the tahoe directory found
> in $BASEDIR/private/root_dir.cap onto the mountpoint specified on the
> commandline.  This was more of a shortcut than a design decision.
> Ideally the interface should take a local directory mountpoint and a
> tahoe dircap.
>
> Now, as an extension developer, should I support any of these
> conventions: root_dir.cap, aliases, browser bookmarks?

I'd consider providing alias support. If I could do "fusething mount work:
/mnt/work", then it could look in my ~/.tahoe/aliases for the "work:" alias
and use that dircap for the /mnt/work mount. Of course I'd want "fusething
mount URI:DIR2:... /mnt/work" too.

cheers,
 -Brian