[tahoe-dev] Authority to DoS via WAPI
Toby Murray
toby.murray at comlab.ox.ac.uk
Tue Jan 20 01:37:30 PST 2009
On Mon, 2009-01-19 at 21:29 -0700, zooko wrote:
> Hm. So with this patch, people can use up your disk space if and
> only if they've been given a write-cap.
Correct.
> If they have a write-cap
> only to an SSK file, then all they can do is write a bigger file in
> that SSK slot.
Yes.
> If they have a write-cap to a directory, then they
> can mkdir a new directory, unlink it from its parent, and thereafter
> have unlimited ability to write files or dirs.
Ah, I hadn't thought of this.
Does the slot that each cap designates carry a reference count, in the
current implementation, that counts how many directories refer to that
slot?
One solution would be to have "web.ambient_upload_authority" be a
grid-wide setting (stored in the introducer perhaps) -- which it
probably should be anyway -- and then to have the semantics that when th
is is False, we have that whenever a slot's refcount drops below 1, we
reclaim its space.
I'm beginning to see that my proposal here is at odds with the overall
design philosophy of unlinked slots. The current solution is perhaps too
much of a hack, only half-solving the problem at the expense of adding
complexity. Perhaps it should be reverted.
In the meantime, I'd be interested to get your thoughts on the
implications of the refcounting idea above and any pointers on how such
a thing could be implemented in the current codebase.
> Well, I guess it's a start. Please consider Brian's suggestion to
> make the configuration name even more specific. :-)
I wonder if web.ambient_create_authority would be best.
Cheers
Toby
More information about the tahoe-dev
mailing list