Re: [HACKERS] dblink get_connect_string() passes FDW option"updatable" to the connect string, connection fails.
| От | Corey Huinker |
|---|---|
| Тема | Re: [HACKERS] dblink get_connect_string() passes FDW option"updatable" to the connect string, connection fails. |
| Дата | |
| Msg-id | CADkLM=ebuf9=Pv1kKRnw2Ys7pXqiiDX9vPbe8fzo0P5d8S4hgw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] dblink get_connect_string() passes FDW option"updatable" to the connect string, connection fails. (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: [HACKERS] dblink get_connect_string() passes FDW option"updatable" to the connect string, connection fails.
|
| Список | pgsql-hackers |
On Sun, Dec 18, 2016 at 4:57 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway <mail@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.
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.
В списке pgsql-hackers по дате отправления: