Currently dblink allows regular users to initiate libpq connection
to user-provided connection string. This breaks the default
policy that normal users should not be allowed to freely interact
with outside environment.
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)
The were already couple of hacks added to libpq and dblink that
disallow the re-use of passwords acquired from .pgpass/pg_service.
The hacks make sure the password is used for login and it came
from connection string.
But they take effect *after* login is finished, thus leaving open
even nastier hole - user can *look* at the passwords by simply
directing the connection to host where is a Postgres-emulator
installed that requests plaintext authentication.
Attached patch fixes the problems by allowing only superusers
to specify connection strings.
Instead of playing with permissions, it hardwires the check to
C code for following reasons:
- encouraging use of SECURITY DEFINER functions to choose
the connection string so they are always under control of admin
- discouraging solutions where normal user can freely pick
connection string
- making dblink security similar to other remote-access solutions
which do not let regular user pick connection string (plproxy / dbi-link)
I understand some of current users may dislike the patch as currently
dblink does not give any support for running it securely.
I've outlined possible future API direction here:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01302.php
Mainly this involves creating superuser-controlled name->connstr lookup
mechanism. Either specific to dblink or possibly built into core,
so other remote-access solutions can use it also.
--
marko