tahoe-lafs/trac-2024-07-25

add read-only mode for gateways #1447

New issue

Open

opened 2011-07-27 05:22:27 +00:00 by zooko · 4 comments

zooko commented

2011-07-27 05:22:27 +00:00

Owner

I want to host my blog and other publicly-readable documents on a grid like the Public Test Grid. The operators of the Public Test Grid gateway recently shut it down:

http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006572.html

A potentially good way to run the Public Test Grid, and still allow people to experiment with it, and allow me to host my blog on it, while deterring people from using it as a publishing platform for their controversial files, would be to put the public gateway into read-only mode.

I propose to add a configuration option to the "client" (a.k.a. "gateway") section of tahoe.cfg to make a gateway read-only.

We had talked about making it so the gateway would offer read-only service on one port and read-write service on a different port, but after more reflection I would rather not do that for now. It would be easy for users to misunderstand and think that Tahoe-LAFS was somehow going to prevent unauthorized users from using the more privileged port, when in fact the users would have to set up firewall rules and/or HTTP-level proxies themselves to prevent unauthorized users from connecting to the more privileged port. Also, I have never yet wanted a single gateway process to serve both kinds of access, so this may be a case of YAGNI. In any case, it will definitely be simpler to implement a gateway-wide read-only policy.

I want to host my blog and other publicly-readable documents on a grid like the Public Test Grid. The operators of the Public Test Grid gateway recently shut it down: <http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006572.html> A potentially good way to run the Public Test Grid, and still allow people to experiment with it, and allow me to host my blog on it, while deterring people from using it as a publishing platform for their controversial files, would be to put the public gateway into read-only mode. I propose to add a configuration option to [the "client" (a.k.a. "gateway") section of tahoe.cfg](http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/configuration.rst#client-configuration) to make a gateway read-only. We had talked about making it so the gateway would offer read-only service on one port and read-write service on a different port, but after more reflection I would rather not do that for now. It would be easy for users to misunderstand and think that Tahoe-LAFS was somehow going to prevent unauthorized users from using the more privileged port, when in fact the users would have to set up firewall rules and/or HTTP-level proxies themselves to prevent unauthorized users from connecting to the more privileged port. Also, I have never yet wanted a single gateway process to serve both kinds of access, so this may be a case of YAGNI. In any case, it will definitely be simpler to implement a gateway-wide read-only policy.

tahoe-lafs added the

labels 2011-07-27 05:22:27 +00:00

tahoe-lafs added this to the undecided milestone 2011-07-27 05:22:27 +00:00

zooko commented

2011-07-27 05:47:51 +00:00

Author

Owner

This is related to #587 (gateways provide ambient upload authority). The problem is the same in both cases: gateways provide ambient authority to write (upload) data. This ticket is about a partial solution: make it so you can configure the gateway so that no user can ever write or upload anything. That ticket is, I interpret, about a better, more capability-oriented solution: make it so the requests the user makes to write or upload something come with authorization showing that the gateway should allow them to do so. This also seems to be closely related to the issues of accounting -- #666.

zooko commented

2011-07-27 11:36:01 +00:00

Author

Owner

Implementing this ticket would make it safe to turn on CORS (#1215), for read-only gateways.

davidsarah commented

2011-08-27 01:19:11 +00:00

Author

Owner

Replying to zooko:

We had talked about making it so the gateway would offer read-only service on one port and read-write service on a different port, but after more reflection I would rather not do that for now. It would be easy for users to misunderstand and think that Tahoe-LAFS was somehow going to prevent unauthorized users from using the more privileged port, when in fact the users would have to set up firewall rules and/or HTTP-level proxies themselves to prevent unauthorized users from connecting to the more privileged port. Also, I have never yet wanted a single gateway process to serve both kinds of access, so this may be a case of YAGNI. In any case, it will definitely be simpler to implement a gateway-wide read-only policy.

That would be simpler to implement, yes. OTOH, the SFTP interface requires a login and uses a secure connection, so it isn't subject to the objection above about users having to authenticate access to the privileged port externally to Tahoe. So, we might want to have a configuration option to enable read/write SFTP while disabling other read/write access. But I agree that doesn't need to be part of an initial implementation of this ticket.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/8952): > We had talked about making it so the gateway would offer read-only service on one port and read-write service on a different port, but after more reflection I would rather not do that for now. It would be easy for users to misunderstand and think that Tahoe-LAFS was somehow going to prevent unauthorized users from using the more privileged port, when in fact the users would have to set up firewall rules and/or HTTP-level proxies themselves to prevent unauthorized users from connecting to the more privileged port. Also, I have never yet wanted a single gateway process to serve both kinds of access, so this may be a case of YAGNI. In any case, it will definitely be simpler to implement a gateway-wide read-only policy. That would be simpler to implement, yes. OTOH, the SFTP interface requires a login and uses a secure connection, so it isn't subject to the objection above about users having to authenticate access to the privileged port externally to Tahoe. So, we might want to have a configuration option to enable read/write SFTP while disabling other read/write access. But I agree that doesn't need to be part of an initial implementation of this ticket.

davidsarah commented

2011-10-18 23:13:49 +00:00

Author

Owner

~~(In that case the gateway holds the S3 secrets, so provided those secrets are kept secure, attackers cannot store data in the user's S3 bucket other than via such a gateway.)~~

Correction: the secrets are held on the storage server, and anyone with the introducer FURL can upload. Hmm. So we might also need to fix #860 and make the S3 introducer's FURL unguessable.

This would be particularly useful for users of Tahoe-LAFS-on-S3, who are subject to charges for all data stored, and so could be charged more than they expect if they provide access to a read/write gateway. ~~(In that case the gateway holds the S3 secrets, so provided those secrets are kept secure, attackers cannot store data in the user's S3 bucket other than via such a gateway.)~~ Correction: the secrets are held on the storage server, and anyone with the introducer FURL can upload. Hmm. So we might also need to fix #860 and make the S3 introducer's FURL unguessable.

tahoe-lafs modified the milestone from undecided to 1.10.0

2011-10-18 23:13:49 +00:00

tahoe-lafs modified the milestone from 1.11.0 to soon

2013-08-13 23:05:23 +00:00