pgsql: Repair failure to check that a table is still compatible with a

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Repair failure to check that a table is still compatible with a
Date: 2007-02-02 00:07:28
Message-ID: 20070202000728.610DC9FB26A@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Log Message:
-----------
Repair failure to check that a table is still compatible with a previously
made query plan. Use of ALTER COLUMN TYPE creates a hazard for cached
query plans: they could contain Vars that claim a column has a different
type than it now has. Fix this by checking during plan startup that Vars
at relation scan level match the current relation tuple descriptor. Since
at that point we already have at least AccessShareLock, we can be sure the
column type will not change underneath us later in the query. However,
since a backend's locks do not conflict against itself, there is still a
hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE
while a query is in progress in the current backend. Seal that hole by
rejecting ALTER TABLE whenever the target relation is already open in
the current backend.

This is a significant security hole: not only can one trivially crash the
backend, but with appropriate misuse of pass-by-reference datatypes it is
possible to read out arbitrary locations in the server process's memory,
which could allow retrieving database content the user should not be able
to see. Our thanks to Jeff Trout for the initial report.

Security: CVE-2007-0556

Tags:
----
REL8_2_STABLE

Modified Files:
--------------
pgsql/src/backend/commands:
tablecmds.c (r1.206.2.1 -> r1.206.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c.diff?r1=1.206.2.1&r2=1.206.2.2)
pgsql/src/backend/executor:
execMain.c (r1.280.2.1 -> r1.280.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.280.2.1&r2=1.280.2.2)
execQual.c (r1.199 -> r1.199.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execQual.c.diff?r1=1.199&r2=1.199.2.1)
execScan.c (r1.38.2.1 -> r1.38.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execScan.c.diff?r1=1.38.2.1&r2=1.38.2.2)
execUtils.c (r1.140.2.1 -> r1.140.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execUtils.c.diff?r1=1.140.2.1&r2=1.140.2.2)
nodeAgg.c (r1.146 -> r1.146.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeAgg.c.diff?r1=1.146&r2=1.146.2.1)
nodeGroup.c (r1.65 -> r1.65.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeGroup.c.diff?r1=1.65&r2=1.65.2.1)
nodeHashjoin.c (r1.85 -> r1.85.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeHashjoin.c.diff?r1=1.85&r2=1.85.2.1)
nodeMergejoin.c (r1.82 -> r1.82.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeMergejoin.c.diff?r1=1.82&r2=1.82.2.1)
nodeNestloop.c (r1.43 -> r1.43.2.1)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeNestloop.c.diff?r1=1.43&r2=1.43.2.1)
nodeResult.c (r1.34.2.1 -> r1.34.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeResult.c.diff?r1=1.34.2.1&r2=1.34.2.2)
nodeSubplan.c (r1.80.2.1 -> r1.80.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubplan.c.diff?r1=1.80.2.1&r2=1.80.2.2)
pgsql/src/include/executor:
executor.h (r1.130.2.1 -> r1.130.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/executor.h.diff?r1=1.130.2.1&r2=1.130.2.2)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2007-02-02 00:07:44 pgsql: Repair failure to check that a table is still compatible with a
Previous Message Tom Lane 2007-02-02 00:07:03 pgsql: Repair failure to check that a table is still compatible with a