embed security metadata in parent directory #956

New Issue

zooko · 2010-02-15T06:06:49Z

zooko commented

2010-02-15 06:06:49 +00:00

#954 (revoke write authority), #955 (use client-side storage to defend against rollback attack) and not-yet-ticketed "LAFS 301 Moved Permanently" all involve a small fixed amount of metadata.

A "highest known version number" for a mutable file or directory, which according to #955 could be stored in a client to prevent that client from perceiving a rollback could also be stored in a parent directory which links to that mutable file or directory, thus preventing someone who accesses the file through that parent directory from seeing a rollback to a version earlier than the most recent known version when that child link was last updated.

A LAFS 301 Moved Permanently marker has to be stored in the shares with the file content itself, but it could also be copied into a parent directory that linked to that file, thus optimizing out a round trip to the old location and also preventing a rollback attack from undoing the Moved Permanently (from the perspective of someone accessing the file through that parent directory).

Likewise, a write-authority-revocation marker, a.k.a. a "petrification marker" has to live in the shares next to the file contents itself, but it could also be copied into a directory which links to that file, preventing rollback attack from unpetrifying the file (from the perspective of someone accessing the file through that parent directory).

#954 (revoke write authority), #955 (use client-side storage to defend against rollback attack) and not-yet-ticketed "LAFS 301 Moved Permanently" all involve a small fixed amount of metadata. A "highest known version number" for a mutable file or directory, which according to #955 could be stored in a client to prevent that client from perceiving a rollback could *also* be stored in a parent directory which links to that mutable file or directory, thus preventing someone who accesses the file through that parent directory from seeing a rollback to a version earlier than the most recent known version when that child link was last updated. A LAFS 301 Moved Permanently marker has to be stored in the shares with the file content itself, but it could *also* be copied into a parent directory that linked to that file, thus optimizing out a round trip to the old location and also preventing a rollback attack from undoing the Moved Permanently (from the perspective of someone accessing the file through that parent directory). Likewise, a write-authority-revocation marker, a.k.a. a "petrification marker" has to live in the shares next to the file contents itself, but it could *also* be copied into a directory which links to that file, preventing rollback attack from unpetrifying the file (from the perspective of someone accessing the file through that parent directory).

zooko added the

labels 2010-02-15 06:06:49 +00:00

zooko added this to the undecided milestone 2010-02-15 06:06:49 +00:00

zooko commented

2010-02-15 06:12:58 +00:00

#957 (embed security metadata in URL) is about the complementary feature of embedding this metadata in the URL itself.

davidsarah commented

2010-02-16 00:27:15 +00:00

Replying to zooko:

A "highest known version number" for a mutable file or directory, which according to #955 could be stored in a client to prevent that client from perceiving a rollback could also be stored in a parent directory which links to that mutable file or directory, ...

This can only be done when the client is writing to the directory anyway, since it might cause spurious UncoordinatedWriteErrors to perform directory writes that haven't been explicitly requested. Whenever we do write a directory, however, we can write the last-known-version for each of its children.

There is going to be a compatibility problem with doing this, since we don't (as far as I can see) have anywhere in the directory format to encode new fields that will be ignored by old clients. This will also be a problem with several other proposed features, including deep-verify caps as described in #308, and extensible directories suggested as part of #959.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/6018): > A "highest known version number" for a mutable file or directory, which according to #955 could be stored in a client to prevent that client from perceiving a rollback could *also* be stored in a parent directory which links to that mutable file or directory, ... This can only be done when the client is writing to the directory anyway, since it might cause spurious UncoordinatedWriteErrors to perform directory writes that haven't been explicitly requested. Whenever we do write a directory, however, we can write the last-known-version for each of its children. There is going to be a compatibility problem with doing this, since we don't (as far as I can see) have anywhere in the directory format to encode new fields that will be ignored by old clients. This will also be a problem with several other proposed features, including deep-verify caps as described in #308, and extensible directories suggested as part of #959.

zooko commented

2010-02-16 03:34:04 +00:00

Replying to [davidsarah]comment:2:

There is going to be a compatibility problem with doing this, since we don't (as far as I can see) have anywhere in the directory format to encode new fields that will be ignored by old clients. This will also be a problem with several other proposed features, including deep-verify caps as described in #308, and extensible directories suggested as part of #959.

There is such a place -- the "metadata" associated with each link. That metadata can be supplied by the user through the wapi, but the special key 'tahoe' cannot be written into by the user (any user-supplied keys in the 'tahoe' key are silently ignored); see [Adder.modify()]source:src/allmydata/dirnode.py?rev=4195#L78.

Replying to [davidsarah]comment:2: > > There is going to be a compatibility problem with doing this, since we don't (as far as I can see) have anywhere in the directory format to encode new fields that will be ignored by old clients. This will also be a problem with several other proposed features, including deep-verify caps as described in #308, and extensible directories suggested as part of #959. There is such a place -- the "metadata" associated with each link. That metadata can be supplied by the user through the wapi, but the special key `'tahoe'` cannot be written into by the user (any user-supplied keys in the `'tahoe'` key are silently ignored); see [Adder.modify()]source:src/allmydata/dirnode.py?rev=4195#L78.

warner commented

2010-02-16 05:02:20 +00:00

Wouldn't a "last-known-version" update necessarily propagate all the way up to the rootcap? (since changing the metadata leading out of dirnodeA will update the contents of dirnodeA, so a new version, which needs to be updated in its parent, etc..). This might be a bit of a performance concern.

Also, the webapi code has thrown away the earlier dirnodes by the time it arrives at the terminal node (it only has the last parent and the target child). So we'd have to rejigger the webapi path-traversal code to keep a list of ancestor dirnodes or something to implement all-the-way-up-to-the-rootcap propagation.

Wouldn't a "last-known-version" update necessarily propagate all the way up to the rootcap? (since changing the metadata leading out of dirnodeA will update the contents of dirnodeA, so a new version, which needs to be updated in its parent, etc..). This might be a bit of a performance concern. Also, the webapi code has thrown away the earlier dirnodes by the time it arrives at the terminal node (it only has the last parent and the target child). So we'd have to rejigger the webapi path-traversal code to keep a list of ancestor dirnodes or something to implement all-the-way-up-to-the-rootcap propagation.

zooko commented

2010-02-16 05:45:09 +00:00

Replying to warner:

Wouldn't a "last-known-version" update necessarily propagate all the way up to the rootcap?

Yes, if a client feels compelled to update all parent dirs that it knows point to a node once it has learned about a new highest-known-version for the node. But it could instead opportunistically update parent nodes only when it was going to write to them anyway. This is a trade-off between safety and performance, and I was imagining a design at the better-performane end of the trade-off, requiring no extra writes to parent nodes. If we keep the highest-known-version info persistently in the client (per #955) then there would sometimes be useful highest-known-version information available locally when we are about to write to a dirnode for other reasons.

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/956#issuecomment-75536): > Wouldn't a "last-known-version" update necessarily propagate all the way up to the rootcap? Yes, if a client feels compelled to update all parent dirs that it knows point to a node once it has learned about a new highest-known-version for the node. But it could instead opportunistically update parent nodes only when it was going to write to them anyway. This is a trade-off between safety and performance, and I was imagining a design at the better-performane end of the trade-off, requiring no extra writes to parent nodes. If we keep the highest-known-version info persistently in the client (per #955) then there would sometimes be useful highest-known-version information available locally when we are about to write to a dirnode for other reasons.

davidsarah commented

2010-02-16 06:21:38 +00:00

Note that if you have #957 (embed security metadata in URL), then the opportunistic update form of this ticket becomes easy, because you can rewrite the URI of each child (assuming that the metadata is in the Tahoe URI proper, rather than a parameter to the webapi URL).

OTOH, writing it to the metadata (say as tahoe:last_known_version) of the directory entry would have better backward compatibility, since it wouldn't involve changing URI formats.

Note that if you have #957 (embed security metadata in URL), then the opportunistic update form of this ticket becomes easy, because you can rewrite the URI of each child (assuming that the metadata is in the Tahoe URI proper, rather than a parameter to the webapi URL). OTOH, writing it to the metadata (say as `tahoe:last_known_version`) of the directory entry would have better backward compatibility, since it wouldn't involve changing URI formats.

zooko modified the milestone from undecided to 2.0.0

2010-02-23 03:11:03 +00:00

zooko added

enhancement

and removed

defect

labels 2011-01-16 03:58:49 +00:00

meejah commented

2021-03-30 18:40:46 +00:00

Ticket retargeted after milestone closed (editing milestones)

meejah removed this from the 2.0.0 milestone 2021-03-30 18:40:46 +00:00

Sign in to join this conversation.