On Sun, Dec 18, 2016 at 4:57 PM, Michael Paquier <michael.paqu...@gmail.com>
wrote:
> On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway <m...@joeconway.com> wrote:
> > Maybe if "CREATE FOREIGN DATA WRAPPER" had a way to specify that the FDW
> > supports a libpq connection it would make sense to allows other FDWs
> > with this attribute, but since there is none the current state strikes
> > me as a bad idea.
> >
> > Thoughts?
>
> libpq is proper to the implementation of the FDW, not the wrapper on
> top of it, so using in the CREATE FDW command a way to do the
> decision-making that does not look right to me. Filtering things at
> connection attempt is a better solution.
> --
> Michael
>
The only benefit I see would be giving the user a slightly more clear error
message like ('dblink doesn't work with %', 'mysql') instead of the error
about the failure of the connect string generated by the options that did
overlap.
Gaming out the options of a Wrapper X pointing to server Y:
1. Wrapper X does not have enough overlap in options to accidentally create
a legit connect string:
Connection fails, user gets a message about the incompleteness of the
connection.
2. Wrapper X has enough options (i.e. user+host+dbname,etc) to generate a
legit connect string (with matching port), but server+port pointed to by X
isn't listening or doesn't speak libpq:
Connection fails, user gets an error message.
3. Wrapper X has enough options (i.e. user+host+dbname,etc) to generate a
legit connect string (without matching port), but server+5432 pointed to by
X doesn't speak libpq:
Whatever *is* listening on 5432 has a chance to try to handshake
libpq-style, and I guess there's a chance a hostile service listening on
that port might know enough libpq to siphon off the credentials, but the
creds it would get would be to a pgsql service on Y and Y is already
compromised. Also, that vulnerability would exist for FDWs that do speak
libpq as well.
4. Wrapper X has enough overlap in options to create a legit connect string
which happens to speak libpq:
Connection succeeds, and it's a feature not a bug.
