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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
