On Sunday 01 July 2007 13:15, Gregory Stark wrote: > "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. >
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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate