Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security
Jacob Champion <jchampion@timescale.com>
From: Jacob Champion <jchampion@timescale.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Mark Dilger <mark.dilger@enterprisedb.com>, Jeff Davis <pgsql@j-davis.com>, Amit Kapila <amit.kapila16@gmail.com>, Andrew Dunstan <andrew@dunslane.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-03-11T00:00:19Z
Lists: pgsql-hackers
On Thu, Mar 9, 2023 at 6:17 AM Robert Haas <robertmhaas@gmail.com> wrote: > That seems like a circular argument. If you call the problem the > confused deputy problem then the issue must indeed be that the deputy > is confused, and needs to talk to someone else to get un-confused. But > why is the deputy necessarily confused in the first place? Our deputy > is confused because our code to decide whether to proxy a connection > or not is super-dumb, No, I think our proxy is confused because it doesn't know what power it has, and it can't tell the server what power it wants to use. That problem is independent of the decision to proxy. You're suggesting strengthening the code that makes that decision -- adding an oracle (in the form of a DBA) that knows about the confusion and actively mitigates it. That's guaranteed to work if the oracle is perfect, because "perfect" is somewhat tautologically defined as "whatever ensures secure operation". But the oracle doesn't reduce the confusion, and DBAs aren't perfect. If you want to add a Sheriff Andy to hold Barney Fife's hand [1], that will absolutely make Barney less of a problem, and I'd like to have Andy around regardless. But Barney still doesn't know what's going on, and when Andy makes a mistake, there will still be trouble. I'd like to teach Barney some useful stuff. > but if there's an intrinsic reason it can't be > smarter, I don't understand what it is. Well... I'm not well-versed enough in this to prove non-existence of a solution. Can you find a solution, using the current protocol, that doesn't make use of perfect out-of-band knowledge? We have a client that will authenticate using any method the server asks it to, even if its user intended to use something else. And we have a server that can eagerly skip client authentication, and then eagerly run code on its behalf, without first asking the client what it's even trying to do. That would be an inherently hostile environment for *any* proxy, not just ours. Thanks, --Jacob [1] https://en.wikipedia.org/wiki/The_Andy_Griffith_Show#Premise_and_characters
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix possible crash in tablesync worker.
- b5c517379a40 16.0 landed
-
Display 'password_required' option for \dRs+ command.
- 19e65dff38bd 16.0 landed
-
Restart the apply worker if the 'password_required' option is changed.
- c1cc4e688b60 16.0 landed
-
Fix possible logical replication crash.
- e7e7da2f8d57 16.0 landed
-
Add new predefined role pg_create_subscription.
- c3afe8cf5a1e 16.0 landed
-
Expand AclMode to 64 bits
- 7b378237aa80 16.0 cited
-
More cleanup of a2ab9c06ea.
- 96a6f11c0625 15.0 landed
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 landed
-
Improve table locking behavior in the face of current DDL.
- 2ad36c4e44c8 9.2.0 cited