Re: dblink connection security - Mailing list pgsql-patches

From Tom Lane
Subject Re: dblink connection security
Date
Msg-id 18042.1183327998@sss.pgh.pa.us
Whole thread Raw
In response to Re: dblink connection security  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: dblink connection security  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: dblink connection security
Next
From: Tom Lane
Date:
Subject: Re: SPI-header-files safe for C++-compiler