On Thu, Aug 31, 2017 at 6:02 AM, Richard Guo <guofenglinux@gmail.com> wrote:
> Is this expected behavior?
I don't think so. My impression after brief research is that this is
a bug introduced here:
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL8_3_0 [eedb068c0] 2008-01-03 21:23:15 +0000
Branch: REL8_2_STABLE Release: REL8_2_6 [3af35f8d4] 2008-01-03 21:23:45 +0000
Branch: REL8_1_STABLE Release: REL8_1_11 [46cf9c260] 2008-01-03 21:24:26 +0000
Branch: REL8_0_STABLE Release: REL8_0_15 [108b19d86] 2008-01-03 21:25:00 +0000
Branch: REL7_4_STABLE Release: REL7_4_19 [230d5cfc4] 2008-01-03 21:25:34 +0000
Branch: REL7_3_STABLE Release: REL7_3_21 [218cf59b6] 2008-01-03 21:25:58 +0000
Make standard maintenance operations (including VACUUM, ANALYZE, REINDEX, and CLUSTER) execute as the table owner
ratherthan the calling user, using the same privilege-switching mechanism already used for SECURITY DEFINER
functions. The purpose of this change is to ensure that user-defined functions used in index definitions cannot
acquirethe privileges of a superuser account that is performing routine maintenance. While a function used in an
indexis supposed to be IMMUTABLE and thus not able to
do anything very interesting, there are several easy ways around that restriction; and even if we could plug them
all,there would remain a risk of
reading sensitive information and broadcasting it through a covert channel such as CPU usage.
To prevent bypassing this security measure, execution of SET SESSION AUTHORIZATION and SET ROLE is now forbidden
withina SECURITY
DEFINER context.
Thanks to Itagaki Takahiro for reporting this vulnerability.
Security: CVE-2007-6600
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company