[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:  davidsarah
     Type:  defect                                                                                |          Status:  assigned  
 Priority:  critical                                                                              |       Milestone:  1.6.0     
Component:  code-dirnodes                                                                         |         Version:  1.5.0     
 Keywords:  integrity forward-compatibility backward-compatibility confidentiality review-needed  |   Launchpad_bug:            
--------------------------------------------------------------------------------------------------+

Comment(by kevan):

 I've read through this ticket, and I want to make sure that I understand
 what the proposed solution is before I start reviewing it.

 The motivating problem (originally, at least) is that immutable
 directories were allowed to have mutable children. This goes against the
 expectation that the contents of an immutable directory are themselves
 immutable, as stated in comment:3. The problem them expanded to include
 dealing with how clients from the present deal with caps from the future.

 The solution that I think ended up being the one that everyone agreed with
 was stated in comment:21. This was further elaborated on in comment:27.
 Paraphrasing:

   * When reading an immutable directory, caps that we can interpret, and
 that are known to be mutable should be omitted entirely. When writing an
 immutable directory, the existence of caps that are mutable should be
 cause for an error and a failure.
   * When reading an immutable directory, unknown caps in the {{{rw_uri}}}
 slot should be silently ignored, and unknown caps in the {{{ro_uri}}} slot
 should have an {{{ro.}}} or {{{imm.}}} prefix removed, and replaced with
 an {{{imm.}}} prefix. When writing an immutable directory, unknown caps in
 the {{{ro_uri}}} slot should be prefixed with {{{imm.}}} if they are not
 already, and the existence of unknown caps in the {{{rw_uri}}} slot should
 be cause for an error and a failure. (extrapolating from comment:20)
   * When reading a mutable directory, unknown caps in the {{{rw_uri}}}
 slot should be passed through as normal. When writing a mutable directory,
 unknown caps in the {{{rw_uri}}} slot should be passed through as normal,
 and unknown caps in the {{{ro_uri}}} slot should have any existing prefix
 removed and replaced with {{{ro.}}}.
   * When presented with a cap prefixed with {{{imm.}}} or {{{ro.}}},
 webapi servers should see if it is a cap that they understand without the
 prefix. If it is, they should attempt to verify that it matches the prefix
 -- in other words, that it is immutable if prefixed with {{{imm.}}} (this
 is suggested in comment:29).

 Have I misunderstood anything? Have I missed anything? If not, I'll accept
 this ticket and start reviewing it.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/833#comment:43>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid