Re: dblink connection security - Mailing list pgsql-patches

From Gregory Stark
Subject Re: dblink connection security
Date
Msg-id 876453g58n.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: dblink connection security  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: dblink connection security  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> I like this approach better than removing public execute privileges
> on the functions, for two reasons:
>
> * A routine minor version update would install the security fix into
> existing installations, without need for any DBA intervention.
>
> * It does not take away functionality that has perfectly legitimate uses.

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. Even if libpq prevents you
   from doing much because it looks for the libpq protocol messages it would
   still allow, for example, an attacker to do a port probe and see what
   services are running on other hosts on the internal network.

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.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com


pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: dblink connection security
Next
From: Joe Conway
Date:
Subject: Re: dblink connection security