[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      |   Launchpad_bug:          
---------------------------+------------------------------------------------

Comment(by davidsarah):

 Replying to [comment:5 warner]:
 > On the phone, Zooko and I discussed the following plan:
 >
 >  * in the WUI (i.e. the HTML directory-listing pages), when rendering an
 immutable directory, any recognized-as-mutable objects therein should be
 presented just like unrecognized objects (i.e. caps from the future). In
 other words, the WUI for immdirs will only generate download/list
 hyperlinks for objects that are recognized as immutable. It will generate
 non-hyperlinked child names for the unknown/illegal objects. The "More
 Info" page will still list the mutable objects's read/writecaps.
 >  * do the same in the t=json webapi: objects that are not recognized as
 mutable will be returned with {{{type="unknown"}}} instead of
 {{{type="filenode"}}} or {{{type="dirnode"}}}. This will cause the CLI
 "tahoe ls" command to display the object with a question mark instead of
 as a file or directory. The dictionary of properties on the unknown object
 will still include {{{rw_uri}}} and {{{ro_uri}}}.
 >  * the "tahoe cp" command, when faced with an unknown object, should
 print a stderr message and skip over the object. So doing a "cp -r" of a
 tahoe source directory that contains unknown objects will result in a
 smaller target directory which does not contain them.

 I'm a bit concerned that this approach would make it too easy to
 inadvertently write a webapi client that fails to enforce the restriction.
 Also, having to duplicate the check in all frontends seems like an
 indication that it is being checked at the wrong layer, i.e. that the
 webapi should be enforcing it instead.

 Is there any reason why such entries need to be accessible at all? It
 doesn't seem different from any other incorrectly encoded directory entry,
 which might not be accessible.

 >
 >
 > This will raise a barrier in front of casual access to these "illegal"
 files, and any user with a conforming client can be confident that their
 {{{tahoe cp -r $IMM_DIR_NODE ./herlocal}}} command will output the same
 files that your command (using your conforming client) did. If they really
 try hard (by manually retrieving the caps and linking them into a new
 parent directory), they can copy these illegal mutable files, but Tahoe's
 standard tools won't do it for them. (i.e. we don't have to completely
 hide these objects, we just have to make sure that "tahoe cp" and "tahoe
 get" and the WUI won't give you their contents)
 >
 > davidsarah: yeah, immutable directories should always (modulo broken
 hash functions) represent DAGs.. that should be part of the definition.

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