[tahoe-dev] Authority to DoS via WAPI

Toby Murray toby.murray at comlab.ox.ac.uk
Mon Jan 19 12:10:47 UTC 2009


On Sun, 2009-01-18 at 11:30 -0700, zooko wrote:
> Thanks, Toby!
> 
> I applied your patch, [3440], and I have the following comments or  
> requests about it:
> 
> 1.  Please add doc to http://allmydata.org/trac/tahoe/browser/docs/ 
> configuration.txt about this option.  Possibly in http:// 
> allmydata.org/trac/tahoe/browser/docs/frontends/webapi.txt as well.

Will do.


> 2.  Do I understand correctly that this prevents people from doing  
> any PUTs or POSTs to URLs that begin with "uri/"?

No. It (should) prevent people from doing PUTs and POSTs only to URLs
whose path is "/uri" -- not to URLs that contain caps. 

>   That seems just  
> about right -- it prevents adding new files or changing the contents  
> of files even if you know the write-cap to a file or a directory.

No. It prevents adding new unlinked files or creating new unlinked
directories. This is because these operations do not require a
capability. Hence they provide ambient authority to anyone that can
create an HTTP connection to your node. Hence,
"ambient_upload_authority" -- maybe this should be called
"ambient_create_authority" but I don't think the name is a big deal.

I'll embellish the current test code to save one of the URLs returned
from a create-unlinked-directory operation and then test that once
web.ambient_upload_authority = false, we can still upload files and
create subdirs of that directory.

Could you confirm my manual test results (just performed while writing
this email) that web.ambient_upload_authority = false does indeed allow
one to upload new files and create new sub-directories provided one has
a write-cap to a directory.
   
> But what about the check, verify, repair, manifest, and stats  
> commands listed at the end of webapi.txt. 

These operations all require a $URL or $DIRURL, neither of which have
been defined. If these are caps, (are they verify-caps?) then that seems
fine. 

>  I'm not 100% sure why we  
> made these available through POST instead of through GET -- perhaps  
> because they have the "side effect" of causing a potentially large  
> amount of CPU, network, and disk work even though they don't have any  
> "side effects" on the filesystem graph of directories and files.   
> Currently, if web.ambient_upload_authority is false then you can't do  
> those check, repair, etc. operations.  Is that what you intend?

No. These operations should still work with web.ambient_upload_authority
= false, since they require a cap and therefore are not providing
ambient authority.


> 3.  Maybe for the test we could use du() from fileutil (http:// 
> allmydata.org/trac/tahoe/browser/src/allmydata/util/fileutil.py ,  
> also known as http://allmydata.org/trac/pyutil/browser/pyutil/pyutil/ 
> fileutil.py ) to assert that the filesystem usage on the server isn't  
> greater after the client attempted to upload something.

I'll look into this.

Cheers

Toby




More information about the tahoe-dev mailing list