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?


Reply via email to