Re: Non-superuser subscription owners

On Tue, Jan 24, 2023 at 5:50 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I think this has some potential, but it's pretty complex, seeming to
> require protocol extensions and having backward-compatibility problems
> and so on.

Yeah.

> What do you think about something in the spirit of a
> reverse-pg_hba.conf? The idea being that PostgreSQL facilities that
> make outbound connections are supposed to ask it whether those
> connections are OK to initiate.  Then you could have a default
> configuration that basically says "don't allow loopback connections"
> or "require passwords all the time" or whatever we like, and the DBA
> can change that as desired.

Well, I'll have to kick the idea around a little bit. Kneejerk reactions:

- It's completely reasonable to let a proxy operator restrict how that
proxy is used. I doubt very much that a typical DBA wants to be
operating an open proxy.

- I think the devil will be in the details of the configuration
design. Lists of allowed destination authorities (in the URI sense),
options that must be present/absent/overridden, those sound great. But
your initial examples of allow-loopback and require-passwords options
are in the "make the DBA deal with it" line of thinking, IMO. I think
it's difficult for someone to reason through those correctly the first
time, even for experts. I'd like to instead see the core problem --
that *any* ambient authentication used by a proxy is inherently risky
-- exposed as a highly visible concept in the config, so that it's
hard to make mistakes.

- I'm inherently skeptical of solutions that require all clients --
proxies, in this case -- to be configured correctly in order for a
server to be able to protect itself. (But I also have a larger
appetite for security options that break compatibility when turned on.
:D)

> > For the hypothetical logon trigger, or any case where the server does
> > something on behalf of a user upon connection, I agree it doesn't help you.
>
> I don't think the logon trigger thing is all *that* hypothetical. We
> don't have it yet, but there have been patches proposed repeatedly for
> many years.

Okay. I think this thread has applicable lessons -- if connection
establishment itself leads to side effects, all actors in the
ecosystem (bouncers, proxies) have to be hardened against making those
connections passively. I know we're very different from HTTP, but it
feels similar to their concept of method safety and the consequences
of violating it.

--Jacob