Re: dblink connection security - Mailing list pgsql-patches
From | Robert Treat |
---|---|
Subject | Re: dblink connection security |
Date | |
Msg-id | 200707011326.00485.xzilla@users.sourceforge.net Whole thread Raw |
In response to | Re: dblink connection security (Gregory Stark <stark@enterprisedb.com>) |
Responses |
Re: dblink connection security
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: dblink connection security (Gregory Stark <stark@enterprisedb.com>) |
List | pgsql-patches |
On Sunday 01 July 2007 13:15, Gregory Stark wrote: > "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. > Did you mean s/trust/ident/g, otherwise I don't think I understand the above... granted the combination of trust for localhost does open a door for remote users if they have access to dblink, but I don't think that's what you were trying to say. > 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. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
pgsql-patches by date: