Re: [patch] fix dblink security hole

Marko Kreen wrote:
> In addition to breaking standard security policy, dblink exposes
> .pgpass/pg_service.conf contents of the OS user database is running
> under to the non-privileged database user.  (Esp. passwords)

I took a look and can partially see Marko's point. The scenario exists 
within this context:

1. "superuser" installs dblink on db1, running on postgres server   under the "superuser" account
2. "superuser" has .pgpass file
3. the "superuser" .pgpass file is set up with wildcards, e.g.   *:*:*:postgres:mypassword
4. "superuser" creates login for "luser" in db1

This depends on "superuser" to not only make use of .pgpass, but 
specifically to use it in an insecure way, i.e. using wildcards to 
specify that the login credentials should be sent to any arbitrary 
Postgres installation.

So although it may make sense to lock this down for 8.4, I don't agree 
with backporting it due to the backward compatibility hit. Also, I think 
we still need a way that people who don't allow real end-users directly 
in their databases and don't care about Marko's threat scenario can get 
their work done with minimal pain.

Attached is my version of a more complete patch. It aims to prevent any 
dblink connection by non-superusers. But it also creates "_u" versions 
of dblink() and dblink_exec(), and initially revokes privileges from 
public in a similar vain. dblink_u(), dblink_exec_u (), and the 
previously created dblink_connect_u() are all SECURITY_DEFINER functions 
that can be granted to trusted non-superuser logins.

Beyond Marko and I, no one else has publicly weighed in on this. If I 
don't hear any objections, I'll apply to cvs HEAD *only* in about 24 hours.

Thanks,

Joe