[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:  davidsarah
     Type:  defect                                           |          Status:  assigned  
 Priority:  critical                                         |       Milestone:  1.6.0     
Component:  code-dirnodes                                    |         Version:  1.5.0     
 Keywords:  integrity forward-compatibility confidentiality  |   Launchpad_bug:            
-------------------------------------------------------------+--------------

Comment(by zooko):

 Replying to [comment:28 davidsarah]:
 > The main remaining issue I haven't quite decided on, is that if we're
 removing the restriction on adding unknown URIs to a directory, we need to
 consider what consistency properties should be guaranteed for reads of
 ''mutable'' directories. If you read a directory entry or entries in a
 single webapi operation, then the {{{rw_uri}}} and {{{ro_uri}}} slots
 should be consistent with each other -- i.e. if both are present then they
 point to the same object, and {{{ro_uri}}} is the read-only version of
 {{{rw_uri}}} (assuming you trust your gateway to ensure that). Actually
 I'm not sure whether the current code guarantees that, but I think it
 does.

 I'm not sure either.  Let's see:
 [source:src/allmydata/nodemaker.py at 4106#L47].  Yes!  If the type is known
 then it takes the most powerful cap and constructs a Node with that, so it
 then performs its own diminish to get the ro-cap from the rw-cap.

 (Note: this is an example of why off-line diminish can be important!  Some
 designs require a round trip with a storage server before you can compute
 the ro-cap given the rw-cap.  Oh but you could include a copy of the ro-
 cap with the rw-cap.  Oh, but then the Tahoe-LAFS storage client couldn't
 be sure that the ro-cap pointed to the same file as the rw-cap.  I hereby
 change my mind about off-line diminish -- I used to think it wasn't as
 important as having very small caps, but now I think it is very
 important.)

 > If unknown caps (i.e. unknown to the webapi server) are allowed to be
 returned in directory reads, then the webapi can't ensure this property
 for such caps. I'm leaning toward just documenting that.

 Should the webapi server tag such caps with something like {{{unk.}}} so
 that the fact that they came from a context where this property couldn't
 be verified is not lost?

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