Re: Non-superuser subscription owners - Mailing list pgsql-hackers
From | Jacob Champion |
---|---|
Subject | Re: Non-superuser subscription owners |
Date | |
Msg-id | CAAWbhmgnLt57UH7j6VECLbxr5G9gAuJX__iXos7kF8fAnY_NqA@mail.gmail.com Whole thread Raw |
In response to | Re: Non-superuser subscription owners (Robert Haas <robertmhaas@gmail.com>) |
Responses |
postgres_fdw, dblink, and CREATE SUBSCRIPTION security
|
List | pgsql-hackers |
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
pgsql-hackers by date: