[tahoe-dev] Authority to DoS via WAPI

[Toby Murray]

On Wed, 2009-01-14 at 14:01 -0700, zooko wrote:
> Toby Murray wrote:
> > It seems strange to require an unguessable (F)URL to join the grid  
> > but not one to consume space on it.
> 
> You're right.  
> But in the meantime, it sure would make sense to have a way to give  
> people read-only access to a grid as a whole.
>
> 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. My basic objection is that there are
operations in the wapi that provide any Internet connected machine with
ambient authority to consume space on any publicly accessible grid. This
seems dangerous and I can think of plenty of cases in which it could be
problematic.

Operations in the wapi that are problematic (i.e. that provide the user
with ambient authority) include:

PUT /uri 
POST /uri?t=mkdir
PUT /uri?t=mkdir
POST /uri?t=upload

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.

I get that this is tricky in the current design since the operations
listed above are needed to bootstrap the first content in a grid.

I'll have a look at writing a patch to disable the methods above,
perhaps via a command-line argument that can be passed when starting a
node. This way, one can bootstrap a grid using these methods before
taking it live and then, when making it publicly accessible, disable
them so that the potential for further modification to a grid can then
be controlled (by how capabilities have been distributed to its initial
bootstrapped contents).
 

As an aside:

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.

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

Cheers for the response

Toby