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

 Replying to [comment:30 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.

 Except that if the most powerful cap is of unknown type,
 {{{_create_from_cap}}} (note the underscore) will return {{{None}}}, so
 {{{create_from_cap}}} will return {{{UnknownNode(writecap, readcap)}}},
 which doesn't ensure that the cap pair is consistent.

 So, the proposed behaviour for 1.6 is identical to the current behaviour
 here: known cap pairs retrieved from the webapi are consistent, but
 unknown ones may not be.

 > (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.)

 What's important here is off-line diminish from a writecap to a readcap.
 All the proposed designs support that. What might not be supported is off-
 line diminish from a short readcap to a verifycap. (Elk Point does not
 support that in cases where the readcap is too short to provide sufficient
 integrity.)

 > > 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?

 What would the webapi client do with that fact? {{{imm.}}} and {{{ro.}}}
 are associated with specific conformance requirements, but {{{unk.}}}
 wouldn't be -- it would just be a hint that the webapi client shouldn't
 assume something. It is easier to document that it shouldn't ever make
 that assumption. (Note that a webapi client could always decode the caps
 and check that they are consistent.)

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