[tahoe-dev] [tahoe-lafs] #833: reject mutable children when *reading* an immutable dirnode

[tahoe-lafs]

#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