[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3785: GBS does not preserve the capability-based access control mechanism to the storage service

[Tahoe-LAFS]

#3785: GBS does not preserve the capability-based access control mechanism to the
storage service
---------------------+---------------------------------------
 Reporter:  exarkun  |          Owner:  exarkun
     Type:  defect   |         Status:  new
 Priority:  normal   |      Milestone:  HTTP Storage Protocol
Component:  unknown  |        Version:  n/a
 Keywords:           |  Launchpad Bug:
---------------------+---------------------------------------
 In the Foolscap-based protocol, a fURL is used to authenticate a storage
 server (using the tub-derived hash) *and* find the storage service (using
 the swissnum).

 It is relatively easy to connect to a Foolscap tub hosting a storage
 service.  All you need to do is scan an address range until you find one.
 To prevent arbitrary clients from allocating arbitrary storage, the
 swissnum makes it *hard* to get the storage service after connecting to
 the Foolscap tub.  If you know the swissnum - a moderately long random
 secret - you can find the storage service; if you don't, you can't.

 GBS uses NURLs which each include a swissnum.  However, the GBS
 specification does not incorporate the swissnum into the protocol at all.
 It places storage service endpoints at predictable, fixed locations (eg
 `/v1/version`).  This means anyone who scans a network and discovers a GBS
 server can use the storage service.

 This eliminates the access control mechanism that was previously in place
 for the Foolscap-based protocol.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3785>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage