"Joe Conway" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings