[tahoe-dev] Authority to DoS via WAPI

[Brian Warner]

> > whenever a slot's refcount drops below 1, we reclaim its space.
>
> I had previously suggested an approach like this to Brian, but I think
> there are some problems with this approach, starting with the classic
> question of how to collect reference cycles, as well as the usage issue
> that people might like to keep caps in their browser bookmarks or post-it
> notes or whatever -- external to the Tahoe system -- to otherwise unlinked
> files and directories. So in terms of garbage collection, there can be a
> large number of roots and we don't necessarily know them all!

In addition, we've got the distributed problem: the race that occurs if you
are removing an object from one directory at the same time that someone else
is adding it to a second directory. There's also the added complication of
read-only references: we need to decide if they should be treated like
weakrefs or strongrefs. This ties in to the access control surrounding these
refcounts: who has the authority to modify the refcount?

 (one approach that I've examined is to make the refcount be a set of named
 references, each of which can be removed only by the holder of the writecap
 to the parent directory. This basically forces read-only refs to be
 weakrefs, which is unfortunate).

> I guess that's really where the discussion should start: the relationship
> between that person who values that file, and you who operate a storage
> server. Why should you keep that share intact on behalf of that person?
> What responsibilities do they have to fulfill in order that you'll agree to
> keep that share for them (such as regularly refreshing a "lease" on that
> share, or agreeing to pay the bills that you send for having held that
> share)? How long are you willing to agree to keep that share for them --
> weeks? years? decades?

My current thinking is that the only sensible way to approach this is in
terms of leases. (that is, this is the most understandable and predictable
approach, giving the client enough information to work correctly).

The storage server operator grants a lease on some share (possibly in
exchange for money or space-in-trade or whatever) for some pre-agreed period
of time. The client can assume that a reliable server will not delete the
share before the lease period has expired, and will not expect the share to
outlive the lease. The server might be willing to renew the lease before it
expires, and the client has the option of cancelling the lease early, but
otherwise the client can make plans based upon that share being available for
a well-known duration.

The server might be willing to make long-term leases for close friends, or
stick to short-term leases because they might want to use that disk space for
something else soon. The client might be unwilling to take short-term leases
(because they don't want to spend the bandwidth to move the shares later), or
they might be willing to pay more for a longer-term lease.

With leases, the storage-server API becomes:

 upload share (and claim a lease of some duration)
 renew lease (or be denied)
 cancel lease

Each share has a set of leases: when the last lease is cancelled or expires,
the share can be deleted. Each lease is a separate object, with a renew-cap
and a cancel-cap.

The client's responsibility is to maintain leases on everything they care
about. If they have dircaps kept in bookmarks, or written down on napkins, or
tattooed on their arm (but beneath their t-shirt, to keep them secret :-),
they know that they must do a deep-traverse-and-renew from those starting
points before the leases expire. The lease duration that they get determines
how frequently they must perform this ritual.

If leases interact with accounting, there may also be an "enumerate leases"
API, or some sort of reconcilliation API ("here's the list of shares I want
to keep alive, please renew a lease on all of them, and cancel the lease on
anything that's not on this list"). The server might be interested in the sum
of sizes for every share on which a given user is holding a lease, as a form
of aggregate storage consumption. They might even want to charge them money
based upon this number. This makes the incentives clear: clients want to
cancel leases on deleted files quickly, to spend less money, while servers
want to delete shares as soon as the leases expire, to spend less disk
(making it free for other paying clients to use). Clients who only have a
passing interest in a file and who don't want to spend the money might hold a
readcap but not take out a lease: this is basically a weakref, where that
client depends upon other users to keep the file alive.

I'm still trying to write up my Accounting ideas, but leases are a central
part of them (each lease would have a "label" associated with a user or
account of some sort). Maybe I'll get something put together later this week.

cheers,
 -Brian