Re: GRANT USAGE on FOREIGN SERVER exposes passwords

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Yetter <nyetter(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GRANT USAGE on FOREIGN SERVER exposes passwords
Date: 2015-02-11 13:41:20
Message-ID: 1987.1423662080@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 2/5/15 10:48 AM, Tom Lane wrote:
>> The dblink example is entirely uncompelling, given that as you said
>> somebody with access to a dblink connection could execute ALTER USER on
>> the far end.

> Actually, you can eliminate that by not granting direct access to dblink
> functions. Instead you create a SECURITY DEFINER function that sanity
> checks the SQL you're trying to run and rejects things like ALTER USER.
> While you're doing that, you can also lock away the connection
> information. A former coworker actually built a system that does this,
> at least to a limited degree.

... but if you aren't giving the untrusted user direct access to the
connection, then he also doesn't get to see its options in the view.
So this still isn't compelling, so far as dblink goes.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2015-02-11 13:44:18 Re: 9.6 Feature help requested: Inclusion Constraints
Previous Message Magnus Hagander 2015-02-11 13:31:44 Re: reducing our reliance on MD5