Re: dblink connection security

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> I like this approach better than removing public execute privileges
> on the functions, for two reasons:
>
> * A routine minor version update would install the security fix into
> existing installations, without need for any DBA intervention.
>
> * It does not take away functionality that has perfectly legitimate uses.

I think there are two problems with this:

a) dblink still shouldn't allow arbitrary users to open arbitrary tcp/ip
sockets or unix sockets from the server. That's still a security threat
even if we close Postgres's vulnerability to it. Even if libpq prevents you
from doing much because it looks for the libpq protocol messages it would
still allow, for example, an attacker to do a port probe and see what
services are running on other hosts on the internal network.

b) For a situation like a homebrew replication system someone may want to have
set up a second server which allows passwordless access from the first
server. In which case it is entirely sane (though it doesn't seem to be the
best idea imho) to use ident and requiring a password is removing
functionality that has a perfectly legitimate use.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com