Web nodes provide ambient upload authority #587

New Issue

tahoe-lafs · 2009-01-17T01:47:14Z

toby.murray commented

2009-01-17 01:47:14 +00:00

Under the current webapi, nodes offer ambient upload authority to any host that can send them web requests. There are deployment scenarios for Tahoe in which this behaviour is undesirable.

A means to disable this behaviour would be useful. In particular, being able to turn this behaviour off via a setting in tahoe.cfg could be good.

Discussion surrounding this issue can be found in the thread starting here:
http://allmydata.org/pipermail/tahoe-dev/2009-January/001015.html

Under the current webapi, nodes offer ambient upload authority to any host that can send them web requests. There are deployment scenarios for Tahoe in which this behaviour is undesirable. A means to disable this behaviour would be useful. In particular, being able to turn this behaviour off via a setting in tahoe.cfg could be good. Discussion surrounding this issue can be found in the thread starting here: <http://allmydata.org/pipermail/tahoe-dev/2009-January/001015.html>

tahoe-lafs added the

labels 2009-01-17 01:47:14 +00:00

tahoe-lafs added this to the undecided milestone 2009-01-17 01:47:14 +00:00

toby.murray commented

2009-01-17 01:49:50 +00:00

Attachment patch.ambient_upload_authority (6121 bytes) added

A patch to add 'web.ambient_upload_authority' as a paramater to tahoe.cfg

**Attachment** patch.ambient_upload_authority (6121 bytes) added A patch to add 'web.ambient_upload_authority' as a paramater to tahoe.cfg

patch.ambient_upload_authority

6.0 KiB

toby.murray commented

2009-01-17 01:50:30 +00:00

Attachment test_ambient_upload_authority.py (3833 bytes) added

A test case for this configuration parameter with one test for each of its two boolean states

**Attachment** test_ambient_upload_authority.py (3833 bytes) added A test case for this configuration parameter with one test for each of its two boolean states

test_ambient_upload_authority.py

3.7 KiB

zooko commented

2009-01-18 15:45:04 +00:00

Thanks! I'm looking at your patch.

zooko self-assigned this 2009-01-18 15:45:04 +00:00

zooko commented

2009-01-18 17:24:58 +00:00

fixed by changeset:66f83c7356a79978. I have some more questions about this topic which I'll post to the mailing list.

zooko added the

fixed

label 2009-01-18 17:24:58 +00:00

zooko closed this issue

2009-01-18 17:24:58 +00:00

tahoe-lafs removed the

fixed

label 2010-04-25 20:35:33 +00:00

tahoe-lafs reopened this issue

2010-04-25 20:35:33 +00:00

francois commented

2010-04-26 11:26:48 +00:00

The patch has been reverted by Zooko.

davidsarah commented

2011-01-06 08:13:15 +00:00

See #1215 (add CORS support), which is blocked by at least this issue.

davidsarah commented

2011-07-31 04:48:38 +00:00

See also #1455, about UI redressing attacks on the ambiently accessible pages.

davidsarah commented

2011-12-12 04:13:43 +00:00

In LAE's Tahoe-LAFS-on-S3 service (and possibly other cases when we have accounting), a customer who made a public gateway accessible would have to pay for storage of any files uploaded via that gateway, which puts a real cramp on sharing.

tahoe-lafs modified the milestone from undecided to 1.10.0

2011-12-12 04:13:43 +00:00

tahoe-lafs modified the milestone from soon to 1.12.0

2015-04-12 21:43:37 +00:00

warner commented

2016-03-22 05:02:25 +00:00

Milestone renamed

warner modified the milestone from 1.12.0 to 1.13.0

2016-03-22 05:02:25 +00:00

warner commented

2016-06-28 18:17:14 +00:00

renaming milestone

warner modified the milestone from 1.13.0 to 1.14.0

2016-06-28 18:17:14 +00:00

exarkun commented

2019-05-29 20:11:02 +00:00

Reading the mailing list thread, it seems like the change was reverted because it only allows the removal of the ambient authority to perform "unlinked" writes - in other words, to create brand new "top-level" shares. This is easily subverted by a malicious client who has any single write-cap for the system.

So is it actually possible to fix this issue without some much larger change - eg, "Accounting"?

Reading the mailing list thread, it seems like the change was reverted because it only allows the removal of the ambient authority to perform "unlinked" writes - in other words, to create brand new "top-level" shares. This is easily subverted by a malicious client who has any single write-cap for the system. So is it actually possible to fix this issue without some much larger change - eg, "Accounting"?

exarkun commented

2020-06-30 14:45:13 +00:00

Moving open issues out of closed milestones.

exarkun modified the milestone from 1.14.0 to 1.15.0

2020-06-30 14:45:13 +00:00

meejah commented

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

Ticket retargeted after milestone closed

meejah modified the milestone from 1.15.0 to soon

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

Sign in to join this conversation.