> > 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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
