The URL of the info page for an unknown dirnode should not grant authority to the containing directory #922

New Issue

tahoe-lafs · 2010-01-21T21:56:08Z

davidsarah commented

2010-01-21 21:56:08 +00:00

For known cap types, the URL of the info page for a dirnode is specific to that directory entry, and does not grant any authority to the containing directory. This is as it should be.

For unknown caps, however, the URL of the info page does include the directory readcap (see the comment at source:src/allmydata/web/directory.py#737).

This grants excess authority -- a user might reasonably expect that info pages do not grant authority to read their containing directory, and it is surprising that this happens only for unknown nodes.

We could still display both the writecap and readcap URIs of the unknown dirnode, by stuffing both of them into the info page URL.

For known cap types, the URL of the info page for a dirnode is specific to that directory entry, and does not grant any authority to the containing directory. This is as it should be. For unknown caps, however, the URL of the info page does include the directory readcap (see the comment at source:src/allmydata/web/directory.py#737). This grants excess authority -- a user might reasonably expect that info pages do not grant authority to read their containing directory, and it is surprising that this happens *only* for unknown nodes. We could still display both the writecap and readcap URIs of the unknown dirnode, by stuffing both of them into the info page URL.

tahoe-lafs added the

labels 2010-01-21 21:56:08 +00:00

tahoe-lafs added this to the undecided milestone 2010-01-21 21:56:08 +00:00

davidsarah commented

2010-01-22 00:58:52 +00:00

Note that this is quite difficult to reproduce at the moment because an UnknownNode is not allowed to be stored in a directory by a Tahoe 1.5 or earlier client. Tahoe 1.6 clients (if we finish and review #833 in time, which we're still on course to do) will allow storing unknown nodes. It's quite unlikely that they will be stored accidentally, though, because you will need to submit a JSON body containing an unknown cap (the operations that take a cap in the URL cannot be used for this).

I don't think this is sufficient reason to change the plan to allow adding unknown nodes to directories, because leakage of the directory readcap already happens in other (more likely) cases when you share a file URL that is relative to a directory.

Note that this is quite difficult to reproduce at the moment because an UnknownNode is not allowed to be stored in a directory by a Tahoe 1.5 or earlier client. Tahoe 1.6 clients (if we finish and review #833 in time, which we're still on course to do) will allow storing unknown nodes. It's quite unlikely that they will be stored accidentally, though, because you will need to submit a JSON body containing an unknown cap (the operations that take a cap in the URL cannot be used for this). I don't think this is sufficient reason to change the plan to allow adding unknown nodes to directories, because leakage of the directory readcap already happens in other (more likely) cases when you share a file URL that is relative to a directory.

tahoe-lafs modified the milestone from undecided to 1.7.0

2010-02-01 19:46:03 +00:00

tahoe-lafs modified the milestone from 1.7.0 to 1.7.1

2010-06-12 21:03:44 +00:00

tahoe-lafs modified the milestone from 1.7.1 to 1.8.0

2010-07-11 21:34:44 +00:00

tahoe-lafs modified the milestone from 1.8.0 to soon

2010-08-08 05:33:57 +00:00

Sign in to join this conversation.