#833: reject mutable children when *reading* an immutable dirnode
---------------------------------------------+------------------------------
Reporter: warner | Owner: warner
Type: defect | Status: assigned
Priority: critical | Milestone: 1.6.0
Component: code-dirnodes | Version: 1.5.0
Keywords: integrity forward-compatibility | Launchpad_bug:
---------------------------------------------+------------------------------
Comment(by davidsarah):
Zooko, Brian and I discussed this on IRC, and initially came up with the
following set of options. All the options have in common that when a child
link of an immutable directory is recognized as being mutable, it should
just be omitted. They differ on what should happen with ''unknown'' child
links (i.e. caps from the future):
* OMIT: just omit unknown child links
* NONE: include a directory entry for an unknown child link, but omit
{{{rw_uri}}} and {{{ro_uri}}} from its JSON representation
* RO_URI: include a directory entry with only {{{ro_uri}}}
* UNKNOWN_RO_URI: include a directory entry with a new
{{{unknown_ro_uri}}} field that is used instead of {{{ro_uri}}}. (For
mutable directories, unknown children would have both {{{unknown_rw_uri}}}
and {{{unknown_ro_uri}}} fields.)
* FORWARD_COMPAT_METADATA: standardize a way of recognizing immutable
caps for "all" future versions (say, by the first character after
{{{lafs://}}}), so that non-immutable caps can be excluded without having
to understand their format.
There are also variations of each option according to whether the
restriction is implemented in the webapi code or in !DirectoryNode. If it
is implemented in the webapi, then read-modify-write operations will
preserve unknown caps that aren't directly affected by the operation. I
think we decided that this is preferable because it loses data in fewer
cases -- although it may introduce some inconsistencies between frontends,
unless we manage to fix that for 1.6.
There was concensus that RO_URI option is unsafe (i.e. fails to address
the issue in this bug), because it would be too easy for a {{{ro_uri}}} to
be passed on to another client that understands it, but having lost track
of the constraint that it is supposed to be immutable.
We had already excluded FORWARD_COMPAT_METADATA on the basis that it
requires making decisions that we don't have time to consider carefully
enough for 1.6. UNKNOWN_RO_URI has the advantage of not throwing away
information, but we decided it was too complicated to implement and review
in the time we have. OMIT for 1.6, and FORWARD_COMPAT_METADATA in 1.7,
seemed like a good compromise.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/833#comment:20>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
_______________________________________________
tahoe-dev mailing list
tahoe-dev@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
