[tahoe-lafs-trac-stream] [tahoe-lafs] #795: add-only sets
tahoe-lafs
trac at tahoe-lafs.org
Fri Nov 29 15:12:18 UTC 2013
#795: add-only sets
------------------------------+-----------------------------------------
Reporter: warner | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: undecided
Component: code-mutable | Version: 1.5.0
Resolution: | Keywords: newcaps revocation research
Launchpad Bug: |
------------------------------+-----------------------------------------
Comment (by joepie91):
While #796 is my particular usecase, this seems to be the canonical thread
for the base implementation, so I'll comment here; I was also looking for
write-only caps (in particular append-only directories where you can only
append files and not change, move/rename or remove files), for a write-
only backup mechanism where no single server has the ability to remove any
backups.
In my case, the threat model would be an attacker gaining (full or
partial) access to a server that is being automatically backed up with
Duplicity, intending to irrevocably wipe all data he can. A write-only cap
would make the attacker unable to remove existing backups; only I
personally would be able to do so, using a writecap that is not stored on
any server.
I should also note that there'd be a potential confidentiality issue with
non-read write-only caps (that I expect at least zooko to have already
thought of): if you have a cap that is supposedly intended to prevent any
discovery of data (including a directory listing), how would you reject an
attempt at overwriting an entry (ie. a conflict) without revealing that
the original entry exists, thus causing an information leak and
confidentiality breach?
Either way, I very strongly +1 this write-only-cap suggestion - and I
believe 'appendcap' would be an apt name for it :)
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/795#comment:14>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list