#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
_______________________________________________
tahoe-dev mailing list
tahoe-dev@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
