Re: dblink vs SQL/MED - security and implementation details

Peter Eisentraut wrote:
> Joe Conway wrote:
>> 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...
> 
> Can you elaborate what security issues you are concerned about?

For example: on a freshly installed postgres installation, that does 
*not* require authentication, you would get the following behavior which 
previously was found to be unacceptable:

8<--------------------------------------------------------------
--
-- as the superuser
--
CREATE FOREIGN DATA WRAPPER postgresql LIBRARY 'postgresql_fdw' LANGUAGE C;
CREATE SERVER fdtest FOREIGN DATA WRAPPER postgresql OPTIONS (dbname 'contrib_regression');
CREATE USER dblink_regression_test;
CREATE USER MAPPING FOR dblink_regression_test SERVER fdtest;
\c - dblink_regression_test
psql (8.4devel)
You are now connected to database "contrib_regression" as user 
"dblink_regression_test".
--
-- now as untrusted user dblink_regression_test
--
contrib_regression=> SELECT dblink_connect('myconn', 'fdtest'); dblink_connect
---------------- OK
(1 row)

contrib_regression=> SELECT * FROM dblink('myconn','SELECT 
current_user') AS t(u text);    u
---------- postgres
(1 row)
8<--------------------------------------------------------------

Now, we can blame the superuser for explicitly allowing this, but I 
don't see that as much different from the previously voiced security 
concerns. I'm sure there are other privilege escalation scenarios, but I 
haven't tried at all hard to think of them...

Joe