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
