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

dblink vs SQL/MED - security and implementation details

From: Joe Conway <mail(at)joeconway(dot)com>
To: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: dblink vs SQL/MED - security and implementation details
Date: 2009-01-04 20:34:14
Message-ID: 49611D46.2010900@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackers
(changed the subject to hopefully get a few more eyes looking at this 
thread)

Martin Pihlak wrote:
> 
> I'd vote for allowing aribitrary connect strings -- ordinary users cannot
> create servers and user mappings unless explicitly granted the privileges.
> It probably should be noted in the documentation that allowing ordinary
> users to create user mappings enables the use of postgres .pgpass file.
> Not sure where to put this at the moment.

I'm mainly concerned about re-opening security holes that we spent a lot 
of time debating and subsequently closing. I suspect if we assume that 
any FDW-derived connect string can bypass the checks we put in place, we 
will regret it later. But I'm open to arguments on both sides...

>>> 2. It seems like get_connect_string() is generically useful to any
>>>    client of postgresql_fdw.c -- should it go there instead of dblink?
>> I'm pretty sure get_connect_string() should be moved to postgresql_fdw.c
>> -- objections?
> 
> There is some discussion in another thread about this:
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01875.php
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg00021.php
> 
> The initial approach was to let each foreign data wrapper provide its own
> connection string/list builder function. Latest is to provide the lookup
> functions in foreign.c, and use the same functions for all the different
> fdw's. I was about to implement those but got distracted. Will resume now.

It seems to me that get_connect_string() (or whatever we decide to call 
it), is very libpq specific, and therefore belongs with postgresql_fdw.c 
rather than foreign.c. But if we can't reach a consensus there is no 
harm in leaving it as a dblink.c specific static function either.

Joe

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2009-01-04 21:31:08
Subject: Re: generic reloptions improvement
Previous:From: Martin PihlakDate: 2009-01-04 20:13:42
Subject: Re: dblink vs SQL/MED

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