On Fri, 2023-01-20 at 11:08 -0500, Robert Haas wrote:
> On Fri, Jan 20, 2023 at 8:25 AM Robert Haas <robertmhaas@gmail.com>
> wrote:
> > I still think you're talking about a different problem here. I'm
> > talking about the problem of knowing whether local files are going
> > to
> > be accessed by the connection string.
>
> So here's a dumb patch for this. At least in my mind, the connection
> string sanitization/validation is the major design problem here
I believe your patch conflates two use cases:
(A) Tightly-coupled servers that are managed by the administrator. In
this case, there are a finite number of connection strings to make, and
the admin knows about all of them. Validation is a poor solution for
this use case, because we get into the weeds trying to figure out
what's safe or not, overriding the admin's better judgement in some
cases and letting through connection strings that might be unsafe. A
much better solution is to simply declare the connection strings as
some kind of object (perhaps a SERVER object), and hand out privileges
or inherit them from a predefined role. Having connection string
objects is also just a better UI: it allows changes to connection
strings over time to adapt to changing security needs, and allows a
simple name that is much easier to type and read.
(B) Loosely-coupled servers that the admin doesn't know about, but
which might be perfectly safe to access. Validation is useful here, but
it's a long road of fine-grained privileges around acceptable hosts,
IPs, authentication types, file access, password sources, password
protocols, connection options, etc. The right solution here is to
identify the sub-usecases of loosely-coupled servers, and enable them
(with the appropriate controls) one at a time. Arguably, that's already
what's happened by demanding a password (even if we don't like the
mechanism, it does seem to work for some important cases).
Is your patch targeted at use case (A), (B), or both?
--
Jeff Davis
PostgreSQL Contributor Team - AWS