On 9/12/08, Alvaro Herrera <alvherre@commandprompt.com> wrote:
> Marko Kreen escribió:
>
> > Currently dblink allows regular users to initiate libpq connection
> > to user-provided connection string. This breaks the default
> > policy that normal users should not be allowed to freely interact
> > with outside environment.
>
> Since people is now working on implementing the SQL/MED stuff to manage
> connections, should we bounce this patch? With luck, the CREATE
> CONNECTION (?) stuff will be done for the next commitfest and we can
> just switch dblink to use that instead.
>
> http://archives.postgresql.org/message-id/e51f66da0809050539x1b25ebb9t7fd664fd67b9f607@mail.gmail.com
>
> Thoughts? Can we really expect SQL/MED connection mgmt to be done for
> the next fest?
I will not have time for it. If you want to have it in 8.4,
somebody else needs to step forward.
It should not be that hard actually, for dblink and plproxy only
following is needed (for exact syntax look at sql standard):
- CREATE/ALTER/DROP CONNECTION <name> <details>
- CREATE/DROP USER MAPPING FOR <conn> <user> ... <password>
- system table for connection details
- system table for user mapping - basically access control and passwords
- C API for connection parameter fetching with access control. It should not try to handle actual connections as it's
usersmay have different requirements (eg plproxy wants to use async API for connecting), and anyway it should handle
non-Postgresconnection too in the future.
- invalidation mechanism if info in system tables change
The syntax better be SQL-MED compliant (as far as we want to be).
The SQL-MED seems to define further API for both C and SQL, but there
is no need to try to implement those. As there is simply no need for it.
--
marko
