| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: dblink connection security |
| Date: | 2007-07-01 20:59:43 |
| Message-ID: | 16926.1183323583@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> Tom Lane wrote:
>> I like this approach better than removing public execute privileges
>> on the functions, for two reasons:
> I think this will break backwards compatability though.
Well, revoking public execute will break backwards compatibility too.
If you have a situation where you think it's safe to allow a
non-superuser to get at passwordless connections, you could wrap the
dblink_connect function in a postgres-owned SECURITY DEFINER function.
So either change can be worked around to get the old behavior if necessary.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joe Conway | 2007-07-01 21:12:09 | Re: dblink connection security |
| Previous Message | Robert Treat | 2007-07-01 20:45:01 | Re: dblink connection security |