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

tahoe-lafs trac at allmydata.org
Mon Jan 11 18:47:03 UTC 2010

#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 warner):

 That *is* a good idea, and an explicit form of it should go into
 source:src/allmydata/web/directory.py#L801 (in
 {{{DirectoryJSONMetadata._got}}}), to stomp out the {{{rw_uri}}} return
 if the directory being listed is readonly.

 The directory unpacking function (source:src/allmydata/dirnode.py#L256, in
 {{{DirectoryNode._unpack_contents}}}) will only return a {{{rwcap}}} value
 the dirnode has a writekey, which is only the case for mutable
 (neither mutable dirreadcaps nor immutable directories have a writekey).
 if the {{{rocap}}} value happens to really be a writecap (like if some
 non-conformant implementation placed one there), {{{DirectoryNode.list}}}
 would return a writeable filenode, and then the webapi directory listing
 would get a {{{rw_uri}}} value, and would return it to the client without
 check to explicitly stomp it out.

 (I hadn't previously considered the problem of writecaps stored in the
 column.. for recognized caps, we can block them, but of course we can't
 really say anything about caps-from-the-future).

 But I don't think that's enough. If our claim is that "each time a
 Tahoe client copies out the contents of an immutable directory, they will
 exactly the same", then only serving {{{ro_uri}}} isn't strong enough
 ({{{ro_uri}}} is always read-only, but not always immutable). If some
 non-conformant implementation puts a mutable readcap into an immutable
 directory's {{{ro_uri}}} column, then a conformant client which only
 {{{ro_uri}}} will still enable "tahoe cp" to copy from something mutable,
 then users could see different contents on different copies.

 (If we'd decided to provide an {{{imm_uri}}} in addition to {{{ro_uri}}}
 {{{rw_uri}}}, then maybe we could have omitted everything but
 but we didn't, and besides I think it would have made the dirnode columns
 even more complex).

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

More information about the tahoe-dev mailing list