[tahoe-dev] [tahoe-lafs] #833: reject mutable children when *reading* an immutable dirnode

tahoe-lafs trac at allmydata.org
Mon Jan 18 12:26:05 PST 2010


#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 backward-compatibility confidentiality  |   Launchpad_bug:            
------------------------------------------------------------------------------------+

Comment(by davidsarah):

 Replying to [comment:31 davidsarah]:
 > Replying to [comment:29 zooko]:
 > > (I guess it doesn't ''have'' to enforce security properties on read
 when the purpose of the read is to make a shallow copy of (a subset of)
 the child links into a different Tahoe-LAFS directory,
 >
 > Correct, because it's not decoding those child URIs.
 >
 > > but I feel like it "should" do so in order to be consistent and
 parallel with the other two targets that the information could be headed
 toward: the WUI and the WAPI.)
 >
 > That would mean that a directory operation could have side-effects on
 child links that it isn't defined to alter.

 I misread your comment -- you said a ''different'' directory. However,
 there's no webapi operation that directly copies caps from one directory
 to another. Copying is  implemented by getting the JSON representation of
 a directory, and using {{{mkdir-with-children}}} or {{{mkdir-immutable}}}
 or {{{set-children}}} to create or modify another directory (I assume; I
 haven't looked at the implementation of {{{tahoe cp}}}). So this is
 covered by the validation of known cap pairs that is done on directory
 reads.

 Yes, I think we are out of open issues. Yay for Tahoe 1.6 in Lucid!

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


More information about the tahoe-dev mailing list