Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-04-12 Thread Jacob Champion
On 3/30/23 11:13, Stephen Frost wrote: >> Okay, but this is walking back from the network example you just >> described upthread. Do you still consider that in scope, or...? > > The concern around the network certainly needs to be in-scope overall. Sounds good! > Who are we trusting with what?

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-04-12 Thread Jacob Champion
On 3/30/23 05:58, Robert Haas wrote: > On Fri, Mar 24, 2023 at 5:47 PM Jacob Champion > wrote: >> Okay, but this is walking back from the network example you just >> described upthread. Do you still consider that in scope, or...? > > Sorry, I don't know which example you mean. The symmetrical

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-30 Thread Stephen Frost
Greetings, * Jacob Champion (jchamp...@timescale.com) wrote: > On 3/20/23 09:32, Robert Haas wrote: > > I think this is the root of our disagreement. > > Agreed. I've read all the way back to the $SUBJECT change to try and get an understanding of the questions here and it's not been easy, in

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-30 Thread Robert Haas
On Fri, Mar 24, 2023 at 5:47 PM Jacob Champion wrote: > Okay, but this is walking back from the network example you just > described upthread. Do you still consider that in scope, or...? Sorry, I don't know which example you mean. > > If machines B and C aren't under our control such that we

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-24 Thread Jacob Champion
On 3/20/23 09:32, Robert Haas wrote: > I think this is the root of our disagreement. Agreed. > My understanding of the > previous discussion is that people think that the major problem here > is the wraparound-to-superuser attack. That is, in general, we expect > that when we connect to a

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-20 Thread Robert Haas
On Fri, Mar 10, 2023 at 7:00 PM Jacob Champion wrote: > On Thu, Mar 9, 2023 at 6:17 AM Robert Haas 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

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-10 Thread Jacob Champion
On Thu, Mar 9, 2023 at 6:17 AM Robert Haas 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

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-09 Thread Robert Haas
On Wed, Mar 8, 2023 at 5:44 PM Jacob Champion wrote: > Sure. I don't see a way for the proxy to figure that out by itself, > though, going back to my asymmetry argument from before. Only the > server truly knows, at time of HBA processing, whether the proxy > itself has authority. If the proxy

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-09 Thread Robert Haas
On Wed, Mar 8, 2023 at 5:44 PM Jacob Champion wrote: > > On Wed, Mar 8, 2023 at 11:40 AM Robert Haas wrote: > > On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion > > wrote: > > > I don't think I necessarily like that option better than SASL-style, > > > but hopefully that clarifies it somewhat? >

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-08 Thread Jacob Champion
On Wed, Mar 8, 2023 at 11:40 AM Robert Haas wrote: > On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion wrote: > > I don't think I necessarily like that option better than SASL-style, > > but hopefully that clarifies it somewhat? > > Hmm, yeah, I guess that's OK. Okay, cool. > I still don't love

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-08 Thread Robert Haas
On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion wrote: > > No, that's the opposite, and exactly the point I'm trying to make. In > > that case, the SERVER says what it's willing to accept, and the CLIENT > > decides whether or not to provide that. In your proposal, the client > > tells the server

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-08 Thread Jacob Champion
On Tue, Mar 7, 2023 at 11:04 AM Robert Haas wrote: > > On Thu, Feb 9, 2023 at 4:46 PM Jacob Champion wrote: > > On 2/6/23 08:22, Robert Haas wrote: > > > I don't think that's quite the right concept. It seems to me that the > > > client is responsible for informing the server of what the

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-03-07 Thread Robert Haas
On Thu, Feb 9, 2023 at 4:46 PM Jacob Champion wrote: > On 2/6/23 08:22, Robert Haas wrote: > > I don't think that's quite the right concept. It seems to me that the > > client is responsible for informing the server of what the situation > > is, and the server is responsible for deciding whether

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-02-09 Thread Jacob Champion
On 2/6/23 08:22, Robert Haas wrote: > I don't think that's quite the right concept. It seems to me that the > client is responsible for informing the server of what the situation > is, and the server is responsible for deciding whether to allow the > connection. In your scenario, the client is not

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-02-06 Thread Robert Haas
On Wed, Feb 1, 2023 at 3:37 PM Jacob Champion wrote: > > I'm not an expert on this stuff, but to me that feels like a weak and > > fuzzy concept. If the client is going to tell the server something, > > I'd much rather have it say something like "i'm proxying a request > > from my local user

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-02-01 Thread Jacob Champion
On Mon, Jan 30, 2023 at 2:21 PM Robert Haas wrote: > On Mon, Jan 30, 2023 at 4:12 PM Jacob Champion > wrote: > > For our case, assuming that connections have side effects, one > > solution could be for the client to signal to the server that the > > connection should use in-band authentication

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-01-30 Thread Robert Haas
On Mon, Jan 30, 2023 at 4:12 PM Jacob Champion wrote: > For our case, assuming that connections have side effects, one > solution could be for the client to signal to the server that the > connection should use in-band authentication only; i.e. fail the > connection if the credentials provided

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-01-30 Thread Jacob Champion
On Fri, Jan 27, 2023 at 1:08 PM Robert Haas wrote: > > 1) Forwarding the original ambient context along with the request, so > > the server can check it too. > > Right, so a protocol extension. Reasonable idea, but a big lift. Not > only do you need everyone to be running a new enough version of

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-01-27 Thread Robert Haas
On Wed, Jan 25, 2023 at 6:22 PM Jacob Champion wrote: > Sure: Ambient authority [1] means that something is granted access based > on some aspect of its existence that it can't remove (or even > necessarily enumerate). Up above, when you said "I cannot choose not to > be myself," that's a clear

Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-01-25 Thread Jacob Champion
On 1/24/23 12:04, Robert Haas wrote: > I find the concept of "ambient authentication" problematic. I don't > know exactly what you mean by it. I hope you'll tell me, Sure: Ambient authority [1] means that something is granted access based on some aspect of its existence that it can't remove (or

postgres_fdw, dblink, and CREATE SUBSCRIPTION security

2023-01-24 Thread Robert Haas
[ Changing subject line to something more appropriate: This is branched from the "Non-superuser subscription owners" thread, but the topic has become connection security more generally for outbound connections from a PostgreSQL instance, the inadequacies of just trying to require that such