Re: dblink vs SQL/MED - security and implementation details - Mailing list pgsql-hackers

From Joe Conway
Subject Re: dblink vs SQL/MED - security and implementation details
Date
Msg-id 4963B867.7000509@joeconway.com
Whole thread Raw
In response to Re: dblink vs SQL/MED - security and implementation details  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: dblink vs SQL/MED - security and implementation details  (Peter Eisentraut <peter_e@gmx.net>)
List 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



pgsql-hackers by date:

Previous
From: "Stephen R. van den Berg"
Date:
Subject: Re: Significantly larger toast tables on 8.4?
Next
From: "Alex Hunsaker"
Date:
Subject: Re: Significantly larger toast tables on 8.4?