[tahoe-dev] Server Side Expiration - Ideas

[David-Sarah Hopwood]

On 20/04/12 14:34, rvny at mail.ru wrote:
> Implementation of ideas:
> 
> 1. Add new attribution for folder with label [udelete] then expire.enabled
> 2. Add function, [that] server periodically check task (labels) for delete files,
>    [finds them] and really delete from Hard Disk (from storage folder).

The issue here is who should have authority to delete a file.

For mutable files, it's obvious: a write cap holder has authority to truncate
the file to zero length, so it could reasonably be argued that they should
have the authority to delete.

For immutable files, there are no write caps, and being able to read a
file (or know its contents) should not imply the authority to delete it.

One possibility is to have a powerful authority to delete any file with a
given convergence secret -- or some other secret that is treated similarly to
the convergence secret in that it affects the read cap and storage index.
This may be undesirably powerful.

In any case, Tahoe uses a pure capability security model, so any solution
must be compatible with that, and also with the possibility that the same
file or directory can be referenced from multiple other directories.

-- 
David-Sarah Hopwood ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120420/ad1e3255/attachment.pgp>