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

tahoe-lafs trac at allmydata.org
Thu Jan 28 20:25:55 UTC 2010


#833: reject mutable children when *reading* an immutable dirnode
-------------------------------+--------------------------------------------
     Reporter:  warner         |       Owner:  davidsarah                                                                     
         Type:  defect         |      Status:  closed                                                                         
     Priority:  critical       |   Milestone:  1.6.0                                                                          
    Component:  code-dirnodes  |     Version:  1.5.0                                                                          
   Resolution:  fixed          |    Keywords:  integrity forward-compatibility backward-compatibility confidentiality reviewed
Launchpad_bug:                 |  
-------------------------------+--------------------------------------------

Comment(by davidsarah):

 Phew! After rereading the past discussion, here are a few clarifications
 about how 1.6 will behave:

  * as Brian mentioned in comment:10, a known writecap should not be
 allowed in a {{{ro_uri}}} slot. That is now prevented and tested in
 [source:src/allmydata/test/test_web.py?rev=4195#L3337
 test_mutant_dirnodes_are_omitted] (see {{{mutant_write_in_ro_child}}}).

  * as suggested by Zooko in comment:10, URIs such as "{{{URI:CHK:<a>look
 at me I'm evil<a>}}}" are now treated as unknown (the BadURIError raised
 by, in this case, {{{CHKFileURI.init_from_string}}} is caught by
 [source:src/allmydata/uri.py?rev=4195#L658 uri.from_string]). However they
 are not allowed to be put into directories -- the error thrown by
 {{{init_from_string}}} will be remembered and re-raised if we try to do
 that.

  * the patch does not add an "{{{immutable}}}" field in the JSON
 representation. There's sufficient information to infer it: the dirnode is
 immutable iff the "{{{ro_uri}}}" field holds a known-immutable cap, or
 starts with "{{{imm.}}}", or is omitted. OTOH, that requires a client to
 understand at least the current cap formats, which is undesirable. I'll
 add a ticket for that.

  * there are no "{{{bad_children}}}" or "{{{unrecognized_children}}}" keys
 in the JSON -- we omit bad children, and unrecognized children go under
 the main "{{{children}}}" key.

 Also, note that directory listings containing unknown caps were readable
 with Tahoe '''v1.5''', but not v1.4.1 or earlier versions.

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


More information about the tahoe-dev mailing list