Re: dblink connection security - Mailing list pgsql-patches

From Joe Conway
Subject Re: dblink connection security
Date
Msg-id 4691AEBA.9080206@joeconway.com
Whole thread Raw
In response to Re: dblink connection security  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: dblink connection security
Re: dblink connection security
List pgsql-patches
Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
>> My objection is that I think we should still revoke access for non-superuser
>> by default. The patch makes granting execute reasonable for most users but
>> nonetheless it shouldn't be the default.
>
>> Being able to connect to a postgres server shouldn't mean being able to open
>> tcp connections *from* that server to arbitrary other host/ports.
>
> You forget that dblink isn't even installed by default.  I could see
> having some more verbiage in the documentation explaining these possible
> security risks, but making it unusable is an overreaction.
>

Agreed.

If you are going to argue that we should revoke access for
non-superusers by default for dblink, then you are also arguing that we
should do the same for every function created with any untrusted language.

E.g. as I pointed out to Robert last week, just because an unsafe
function is created in plperlu, it doesn't mean that a non-superuser
can't run it immediately after it is created. There is no difference. It
is incumbent upon the DBA/superuser to be careful _whenever_ they create
any function using an untrusted language.

Joe

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: dblink connection security
Next
From: Gregory Stark
Date:
Subject: Re: dblink connection security