Re: [patch] fix dblink security hole

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Joe Conway" <mail(at)joeconway(dot)com>
Subject: Re: [patch] fix dblink security hole
Date: 2008-09-16 11:59:56
Message-ID: e51f66da0809160459w50ab02fbn2bc1064dd906b7d7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/12/08, Alvaro Herrera <alvherre(at)commandprompt(dot)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 users may
have different requirements (eg plproxy wants to use async API
for connecting), and anyway it should handle non-Postgres connection
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-09-16 12:08:01 Re: Coping with nLocks overflow
Previous Message Simon Riggs 2008-09-16 11:53:43 Subtransaction commits and Hot Standby