Re: Non-superuser subscription owners - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Non-superuser subscription owners
Date
Msg-id CA+TgmoYriYevhHQXKqew=a1_NHnz5n5AR8izLwrWcEJs0fQRXw@mail.gmail.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Jan 23, 2023 at 1:26 PM Andres Freund <andres@anarazel.de> wrote:
> > If I'm asked to attempt to connect to a PostgreSQL server, and I
> > choose to do that, and the connection succeeds, all I know is that the
> > connection actually succeeded.
>
> Well, there is PQconnectionUsedPassword()... Not that it's a great answer.

Sure, but that's making an inference about why the remote side did
what it did. It's not fantastic to have a security model that relies
on connecting to a server chosen by the user and having it tell us
truthfully whether or not it relied on the password. Granted, it won't
lie unless it's been hacked, and we're trying to protect it, not
ourselves, so the only thing that happens if it does lie is that it
gets hacked a second time, so I guess there's no real vulnerability?
But I feel like we'd be on far sounder footing if we our security
policy were based on deciding what we are willing to do (are we
willing to read that file? are we willing to attempt that
authentication method?) and before we actually do it, rather than on
trying to decide after-the-fact whether what we did is OK based on
what the remote side tells us about how things turned out.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Authentication fails for md5 connections if ~/.postgresql/postgresql.{crt and key} exist
Next
From: Andrew Dunstan
Date:
Subject: Re: run pgindent on a regular basis / scripted manner