Обсуждение: 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

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.comPG 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