"Joe Conway" <mail@joeconway.com> writes:
> Robert Treat wrote:
>> Patch based on recent -hackers discussions, it removes usage from public, and
>> adds a note to the documentation about why this is neccessary.
>>
>
> I agree with the fix as the simplest and most sensible approach, and in general
> with the doc change, but I'm not inclined to reference the security paper.
> Maybe something like:
>
> As a security precaution, dblink revokes access from PUBLIC role
> usage for the dblink_connect functions. It is not safe to allow
> remote users to execute dblink from a database in a PostgreSQL
> installation that allows local account access using the "trust"
> authentication method. In that case, remote users could gain
> access to other accounts via dblink. If "trust" authentication
> is disabled, this is no longer an issue.
I think putting the emphasis on Postgresql trust authentication is missing the
broader point. I would suggest two paragraphs such as:
dblink allows any connected user to attempt to connect to TCP/IP or Unix
sockets from the database server as the user the database system is running.
This could allow users to circumvent access control policies based on the
connecting user or the connecting host.
In particular Postgres's "trust" authentication is one such system. It
authenticates connecting users based on the unix userid of the process
forming the connection. In typical configurations any user who is granted
execute access to dblink can form connections as the "postgres" user which is
the database super-user. If "trust" authentication is disabled this is no
longer an issue.
Therefore dblink requires you to explicitly grant execute privileges to users
or roles you wish to allow to form connections. It does not grant these
privileges to the PUBLIC role by default as other packages typically do.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
