Gregory Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq