Gregory Stark <stark@enterprisedb.com> writes:
> 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.
The only way we could enforce that would be to completely disallow
non-superuser use of dblink; ie, "if (!superuser()) elog(ERROR)",
nothing so weak as revoking public execute access. That's a good deal
further than I'm prepared to go, as it really does take away
functionality. And it does it in order to close someone else's security
problem, so I think it's a pretty bad tradeoff.
> 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.
Neither of the proposed fixes prevent that; you can either grant execute
access to appropriate people in the original suggestion, or wrap
dblink_connect in a SECURITY DEFINER function in my new suggestion.
regards, tom lane