[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 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
 value
 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
 if
 the dirnode has a writekey, which is only the case for mutable
 dirwritecaps
 (neither mutable dirreadcaps nor immutable directories have a writekey).
 But
 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
 a
 check to explicitly stomp it out.

 (I hadn't previously considered the problem of writecaps stored in the
 rocap
 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
 conformant
 Tahoe client copies out the contents of an immutable directory, they will
 be
 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
 reports
 {{{ro_uri}}} will still enable "tahoe cp" to copy from something mutable,
 and
 then users could see different contents on different copies.

 (If we'd decided to provide an {{{imm_uri}}} in addition to {{{ro_uri}}}
 and
 {{{rw_uri}}}, then maybe we could have omitted everything but
 {{{imm_uri}}},
 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