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

 I'm not sure I understand everything about your current plan.  However, I
 think I understand that the Tahoe-LAFS storage client has to enforce
 constraints on the semantics of a directory's child links when ''reading''
 the directory, whether it is doing so in order to display the directory in
 the WUI, send a copy of the directory (in JSON form) back through the
 WAPI, or (???) to write a copy of the directory into a new directory in
 Tahoe-LAFS.  (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, 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.)

 But the Tahoe-LAFS storage client doesn't need to enforce any security
 constraints when writing directories -- a malicious client could always
 write arbitrarily bad things into Tahoe-LAFS directories and no-one should
 rely on the assumption that the Tahoe-LAFS directory that they are using
 was written by a client that enforces some security constraints.

 But the storage client ''should'' enforce constraints to help the
 programmer realize that they're trying to do something wrong, when it can
 tell that they are.  That's why it will refuse to put a child link of a
 known type which is mutable into an immutable directory, but it will not
 refuse to put a child link of an unknown type into an immutable directory.

 Okay, so the practice of prepending an {{{imm.}}} to a cap which it
 extracts from an immutable directory is best understood as a security
 constraint that the Tahoe-LAFS storage client enforces on child links of
 immutable directories when it reads them.  It needs to inform any other
 (correct) Tahoe-LAFS clients that eventually receive that cap that the cap
 came from an immutable context.  The prepending of {{{imm.}}} is a way to
 mark the context from which that cap came.

 The reason we can't prepend {{{imm.}}} to every child link from an
 immutable directory and {{{ro.}}} to every link from a {{{ro_uri}}} slot
 is backwards-compatibility -- existing Tahoe-LAFS storage clients need to
 read directories and find caps of known types there and they won't
 recognize {{{ro.}}} or {{{imm.}}}.

 This suggests a forward-compatibility improvement: if you are a Tahoe-LAFS
 storage client ("gateway", "node") and I give you a cap and it has
 {{{imm.}}} on the front of it then you should ''check'' whether it is of a
 type that you recognize and you can tell that the type is immutable.  If
 so, you can pop off the {{{imm.}}} and use the cap.  Likewise with
 {{{ro.}}}.  If Tahoe-LAFS v1.6 storage clients always perform that check,
 then this may free up future versions of the Tahoe-LAFS storage client to
 prepend {{{imm.}}} even to old-type child links (from the Tahoe-LAFS
 v1.6-era), which would be simpler and more consistent than prepending
 {{{imm.}}} only to child links whose type you don't recognize.

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