[tahoe-dev] Authority to DoS via WAPI

[Brian Warner]

> > One hack would be to use the fact that HTTP GETs can't be used to cause
> > side-effects on Tahoe. If you give someone access to a web proxy which
> > passes GETs through but rejects PUTs, POSTs, and DELETEs, then they'll
> > have read-only access to the whole grid.
>
> This isn't quite the same thing.

Well, true.. that's why we've got this "Accounting" project in the works to
control space usage, as opposed to controlling directory modification. These
are independent authorities, so they'll have independent controls. In our
plans, the storage servers delegate storage authority via public/private
keypairs and signed messages, possibly through some intermediaries. Each
space-consuming webapi operation (basically upload file and create directory,
but maybe including grow-file and add-to-directory) must be accompanied by a
suitable proof of storage-authority, with a signature chain that originates
with the server. The server (or its delegates) will provide different forms
of proof to different clients, so the uploaded shares can be identified as
being "counted against" Alice or Bob (so we can answer questions like "How
much space is Alice consuming on this server?").

> I'd prefer a design in which at the time that a grid is created, the
> introducer creates a single write-cap to a directory (the "root" of the
> grid). One then needs to use this writecap to add any content to the
> grid by creating other directories and files that live within them etc.

Ok, but then anyone who is given that writecap (or a writecap to some
subdirectory) gets the ability to upload gigantic files and consume as much
space as they like. This approach splits the world into two classes: people
who have been given any writecap on that grid, and people who have never been
given a writecap. The former can DoS the grid, the latter cannot. The current
unconstrained approach has only the one DoS-enabled class. The hope of our
Accounting project is to offer something finer-grained than that.


> I assume that $DIRCAP in the operation
> POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir&name=NAME
> must a a write-cap to the directory, right? This is OK then.

Yup. $DIRCAP must be a write-cap, and any intermediate SUBDIRS must be linked
via write-caps. (you can add a read-cap to a parent directory, and then
anyone who traverses that read-cap will be limited to read-only access to all
descendants, which will disallow the POST).

> Finally, what does the following (not explained) operation do:
> POST /uri/$FILECAP?t=upload
> Does this update the contents of a mutable file?

Yes. It raises an exception if $FILECAP refers to an immutable file, or to a
read-only facet of a mutable file. Usually that operation is expressed with a
PUT.. the POST form is really just there so the human-oriented "WUI"
interface can provide an HTML form to modify a mutable file.

Thanks for bringing that to my attention.. I'll fix the docs.

cheers,
 -Brian