[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 zooko):

 Brian and I chatted about this on IRC yesterday.  At the end I got sleepy
 and confused about what constraints we impose on the web gateway with
 regard to the JSON-formatted directory listings that it delivers to web
 clients. It is a question of forward-compatibility -- today's web clients
 may read JSON-formatted directory listings from web gateways from the
 future.  This is a separate but related issue to today's web gateways
 (which are also Tahoe-LAFS storage clients) reading distributed
 directories that contain children inserted by other Tahoe-LAFS storage
 clients from the future.  That latter issue is what most of our thinking
 on this ticket has been about so far.

 I'm not sure what to think about that whole idea -- I haven't thought it
 through yet.

 However, now in the light of morning one particular issue that seems clear
 to me is that the test that today's web gateway uses to determine whether
 a given child is a recognized or unrecognized child should be as specific
 as possible as long as it never marks a child from today as unrecognized.
 Brian tells me that {{{uri.from_string("URI:CHK:<a>look at me I'm
 evil<a>")}}} raises a {{{BadURIError}}} instead of what we would probably
 prefer which is to return an {{{UnknownURI}}}.  I don't see why it does
 that from looking at the code.  Here is a map to the relevant code:

 The web gateway (which is a Tahoe-LAFS storage client) unpacks the
 directory contents with [source:src/allmydata/dirnode.py at 4119#L236 its
 internal _unpack_contents() method] and passes the result to its caller
 from [source:src/allmydata/dirnode.py at 4119#L302 its list() method].
 Already looking at the code I want more documentation here.  Could
 {{{list()}}} grow a docstring that tells the caller more about what sorts
 of things it might find in the caps of the children that it returns?

 So the caller in this case takes the caps and passes each one to
 [source:src/allmydata/nodemaker.py at 4106#L47 NodeMaker.create_from_cap()]
 which returns {{{UnknownNode}}} in case both its {{{writecap}}} and
 {{{readcap}}} parameters are empty and then calls
 [source:src/allmydata/uri.py at 4101#L503 uri.from_string()].

 {{{uri.from_string()}}} ''looks'' to me like it is intended to, and does,
 return an {{{UnknownURI}}} instance when the cap is not any of the known
 formats, but Brian says otherwise.

 So my proposals right now are:

  1. We add a docstring explaining what the caller can safely assume about
 the caps returned from {{{DirectoryNode.list()}}}.
  2. We change {{{uri.from_string()}}} to return {{{UnknownURI}}} whenever
 the cap is clearly not a well-formed cap of a known type and add a unit
 test of this.
  3. The JSON listing returned by the wapi excludes mutable children of
 immutable directories entirely.  The presence of one can only mean an
 attack or a bug.  It includes children of unrecognized types, but not in
 the ''children'' node of the JSON object, instead in a sibling node named
 ''unrecognized_children''.  That way wapi-client code written by a lazy
 programmer who doesn't think about the concept of unrecognized children
 will be oblivious to their presence.  This is perhaps suboptimal from a
 UI/UX standpoint, but it is safe.  Code written by more conscientious
 programmer can read the ''unrecognized_children'' node and show those
 children as present but unusable ("greyed-out") for improved UX.

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