dblink for 8.4 should work without user-mappings
contrib/dblink in 8.4 supports a server name by CREATE SERVER for connection
string, but it always requires an user-mapping (by CREATE USER MAPPING).
However, I think it should work user-mappings because it works when
the connection string is passed directly.
=# SELECT * FROM dblink('dbname=postgres', 'SELECT current_user') AS t(i name);
(ok)
=# CREATE FOREIGN DATA WRAPPER postgresql VALIDATOR postgresql_fdw_validator;
=# CREATE SERVER server1 FOREIGN DATA WRAPPER postgresql OPTIONS (dbname 'postgres');
=# SELECT * FROM dblink('server1', 'SELECT 1') AS t(i integer);
ERROR: user mapping not found for "postgres"
The attached patch adds 'missing_ok' parameter to GetUserMapping() and
made dblink to use it. There should be no additional security issues here
because dblink's original security check works even for server name mode.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
Attachments:
dblink-no-user-mapping.patchapplication/octet-stream; name=dblink-no-user-mapping.patchDownload+9-4
On Wednesday 24 June 2009 05:42:01 Itagaki Takahiro wrote:
contrib/dblink in 8.4 supports a server name by CREATE SERVER for
connection string, but it always requires an user-mapping (by CREATE USER
MAPPING). However, I think it should work user-mappings because it works
when the connection string is passed directly.
I had looked into this the other day. I *think* that SQL/MED requires a user
mapping to be present. There are cases where either behavior might be useful,
but we should think about this carefully. It's not simply a question of
security, as you appear to imply.
What happened to this patch?
---------------------------------------------------------------------------
Itagaki Takahiro wrote:
contrib/dblink in 8.4 supports a server name by CREATE SERVER for connection
string, but it always requires an user-mapping (by CREATE USER MAPPING).
However, I think it should work user-mappings because it works when
the connection string is passed directly.=# SELECT * FROM dblink('dbname=postgres', 'SELECT current_user') AS t(i name);
(ok)=# CREATE FOREIGN DATA WRAPPER postgresql VALIDATOR postgresql_fdw_validator;
=# CREATE SERVER server1 FOREIGN DATA WRAPPER postgresql OPTIONS (dbname 'postgres');
=# SELECT * FROM dblink('server1', 'SELECT 1') AS t(i integer);
ERROR: user mapping not found for "postgres"The attached patch adds 'missing_ok' parameter to GetUserMapping() and
made dblink to use it. There should be no additional security issues here
because dblink's original security check works even for server name mode.Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
[ Attachment, skipping... ]
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +Bruce Momjian <bruce@momjian.us> wrote:
What happened to this patch?
It was rejected because SQL standard always requires an user mapping.
I agree about the decision, too.
---------------------------------------------------------------------------
Itagaki Takahiro wrote:contrib/dblink in 8.4 supports a server name by CREATE SERVER for connection
string, but it always requires an user-mapping (by CREATE USER MAPPING).
However, I think it should work user-mappings because it works when
the connection string is passed directly.The attached patch adds 'missing_ok' parameter to GetUserMapping() and
made dblink to use it. There should be no additional security issues here
because dblink's original security check works even for server name mode.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center