Re: dblink vs SQL/MED - security and implementation details

From: Joe Conway <mail(at)joeconway(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: dblink vs SQL/MED - security and implementation details
Date: 2009-01-06 20:00:39
Message-ID: 4963B867.7000509@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> On Tuesday 06 January 2009 05:54:14 Joe Conway wrote:
>> --
>> -- now as untrusted user dblink_regression_test
>> --
>> contrib_regression=> SELECT dblink_connect('myconn', 'fdtest');
>> dblink_connect
>> ----------------
>> OK
>> (1 row)
>
> I think you want some permission checking on fdtest then, right?

I don't see anything documented under GRANT which controls privileges on
a mapping, and the USAGE on a server only controls what a user can see
by query. I assume that if the superuser creates a mapping from user foo
to server bar, foo can still use bar via the mapping, even if they don't
have USAGE granted on the server. It isn't clear from the docs what is
intended, so I could have that wrong.

But even if foo is granted USAGE on bar, I think you miss the point. If you:

1. grant a non-superuser (foo) access to a server (bar)
2. create a mapping for foo to bar which includes no password
3. configure bar to not require authentication (trust)

you will get the privilege escalation as shown (e.g. foo becomes
postgres on bar).

Joe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2009-01-06 20:30:11 Re: Significantly larger toast tables on 8.4?
Previous Message Stephen R. van den Berg 2009-01-06 19:57:41 Re: Significantly larger toast tables on 8.4?