Skip site navigation (1) Skip section navigation (2)

Re: [patch] fix dblink security hole

From: Joe Conway <mail(at)joeconway(dot)com>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] fix dblink security hole
Date: 2008-09-20 23:31:27
Message-ID: 48D587CF.7050005@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackers
I'm clearly out of practice -- this time with the attachment
------------------------------------------------------------

Marko Kreen wrote:
> In addition to breaking standard security policy, dblink exposes
> .pgpass/pg_service.conf contents of the OS user database is running
> under to the non-privileged database user.  (Esp. passwords)

I took a look and can partially see Marko's point. The scenario exists
within this context:

1. "superuser" installs dblink on db1, running on postgres server
    under the "superuser" account
2. "superuser" has .pgpass file
3. the "superuser" .pgpass file is set up with wildcards, e.g.
    *:*:*:postgres:mypassword
4. "superuser" creates login for "luser" in db1

This depends on "superuser" to not only make use of .pgpass, but
specifically to use it in an insecure way, i.e. using wildcards to
specify that the login credentials should be sent to any arbitrary
Postgres installation.

So although it may make sense to lock this down for 8.4, I don't agree
with backporting it due to the backward compatibility hit. Also, I think
we still need a way that people who don't allow real end-users directly
in their databases and don't care about Marko's threat scenario can get
their work done with minimal pain.

Attached is my version of a more complete patch. It aims to prevent any
dblink connection by non-superusers. But it also creates "_u" versions
of dblink() and dblink_exec(), and initially revokes privileges from
public in a similar vain. dblink_u(), dblink_exec_u (), and the
previously created dblink_connect_u() are all SECURITY_DEFINER functions
that can be granted to trusted non-superuser logins.

Beyond Marko and I, no one else has publicly weighed in on this. If I
don't hear any objections, I'll apply to cvs HEAD *only* in about 24 hours.

Thanks,

Joe





Attachment: dblink.2008.08.10.1.diff
Description: text/x-patch (5.5 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Dmitry KoterovDate: 2008-09-21 00:38:56
Subject: Foreign key constraint for array-field?
Previous:From: Joe ConwayDate: 2008-09-20 23:29:08
Subject: Re: [patch] fix dblink security hole

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group