"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> So I guess the scenario is that you're running your database on your
> firewall machine, where it is accessible from outside your net but also can
> reach addresses inside.
Well typically the database is behind the firewall but an application is
outside the firewall and has permission to contact the database. That's a
typical arrangement for a database-backed web application, for example.
> And you're letting untrustworthy outside people log into the database.
Or they've found a security hole in the application which allows
sql-injection. That's why I referred to it as a privilege escalation. Being
able to inject sql means your data is compromised but it shouldn't allow them
to then mount attacks on further systems.
> And you put dblink on it for them to use.
Well consider a hosting provider which installs it at the request of a client
or has a standard set of extensions they want to include in a hosted Postgres
setup.
> And even then, the amount of damage they could do seems pretty limited due
> to lack of control over the packet contents.
Mounting a port scan on an internal network is fairly nasty. They could
discover that you're running some insecure service which can then be
exploited.
> To me this scenario is too far-fetched to justify sacrificing
> convenience and backwards compatibility. It should be sufficient to add
> some paragraphs about security considerations to the dblink docs.
I'm not suggesting making dblink super-user only. Only revoking public execute
bits in the default install script. That doesn't affect users upgrading so I
don't see a backwards-compatibility issue.
The doc changes are going to say to be very careful who you grant access to
dblink to which means not granting public execute access if you have multiple
users. All I'm suggesting is that the default install script should just do
that rather than do something that the docs will then recommend you undo.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
