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


Reply via email to