Re: dblink connection security

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: dblink connection security
Date: 2007-07-09 02:39:11
Message-ID: 20070709023911.GQ4887@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

* Gregory Stark (stark(at)enterprisedb(dot)com) wrote:
> Actually from a security point of view revoking public execute is pretty much
> the same as making a function super-user-only. The only difference is how much
> of a hassle it is for the super-user to grant access. Perhaps we should
> reconsider whether any of the other super-user-only functions should be simply
> not executable by default but work normally if granted.

Revoking public execute on it by default would definitely make me
happier. I could be swayed either way on the explicit super-user check
in the function itself. In the general case, imv we should at least
attempt to consider the risk involved in improper handling of the
permissions around super-user-only functions. Higher risk implies an
extra check in the code to force use of SECURITY DEFINER functions to
work around it, in an attempt to impart the severity of the risk.

Thinking about it a bit more, I'd honestly like to see the check there
for dblink(). That's not entirely fair of me though I suppose, I really
don't feel comfortable with dblink() to begin with and don't expect I'll
ever use it. :)

Thanks,

Stephen

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Gregory Stark 2007-07-09 03:09:54 Re: dblink connection security
Previous Message Stephen Frost 2007-07-09 02:13:53 Re: dblink connection security