Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.
>  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/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.


In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group