Jim Nasby <Jim.Nasby@BlueTreble.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
