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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: dblink vs SQL/MED - security and implementation details
Date: 2009-01-07 12:41:03
Message-ID: 4964A2DF.1030505@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martin Pihlak wrote:
> Usually it would have been the server owner who created those user
> mappings in the first place -- so the passwords are already known
> to him/her. Of course it is possible to create the mappings first
> and later change the ownership of the server, thus exposing the
> passwords to a new role. But IMHO, it would be reasonable to assume
> that the owner of the server has full control over its user mappings.

Maybe we should rethink that. In the SQL standard, it says that USAGE
on the server is required to create a user mapping. I think we could
let users create mappings for their own user name if they have USAGE.
And change the system views so a user can only see his own user mapping
options.

More generally, using passwords in this way is always going to be a
mediocre security solution, since the plaintext password will leak in
all kinds of directions: system catalogs readable by superuser, server
log readable by adm group members (depends on OS), psql_history, etc. I
imagine that a proper authentication solution would involve credentials
forwarding with either Kerberos or SSL or the like.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-01-07 13:04:50 Re: dblink vs SQL/MED - security and implementation details
Previous Message Magnus Hagander 2009-01-07 12:39:17 Re: Including kerberos realm