On Thu, Aug 31, 2017 at 6:02 AM, Richard Guo <guofengli...@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 <t...@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 rather than 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 acquire the privileges of a
superuser account that is performing routine maintenance. While a function
used in an index is 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 within a 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
