Re: dblink connection security - Mailing list pgsql-patches

From Stephen Frost
Subject Re: dblink connection security
Date
Msg-id 20070709023911.GQ4887@tamriel.snowman.net
Whole thread Raw
In response to Re: dblink connection security  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-patches
* Gregory Stark (stark@enterprisedb.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

Attachment

pgsql-patches by date:

Previous
From: Gregory Stark
Date:
Subject: Re: dblink connection security
Next
From: Tom Lane
Date:
Subject: Re: dblink connection security