Skip site navigation (1) Skip section navigation (2)

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:03
Message-ID: 20070202000703.55F7B9FB26A@postgresql.org (view raw or flat)
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

Modified Files:
--------------
    pgsql/src/backend/commands:
        tablecmds.c (r1.212 -> r1.213)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/tablecmds.c.diff?r1=1.212&r2=1.213)
    pgsql/src/backend/executor:
        execMain.c (r1.285 -> r1.286)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c.diff?r1=1.285&r2=1.286)
        execQual.c (r1.210 -> r1.211)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execQual.c.diff?r1=1.210&r2=1.211)
        execScan.c (r1.40 -> r1.41)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execScan.c.diff?r1=1.40&r2=1.41)
        execUtils.c (r1.142 -> r1.143)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execUtils.c.diff?r1=1.142&r2=1.143)
        nodeAgg.c (r1.149 -> r1.150)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeAgg.c.diff?r1=1.149&r2=1.150)
        nodeGroup.c (r1.67 -> r1.68)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeGroup.c.diff?r1=1.67&r2=1.68)
        nodeHashjoin.c (r1.88 -> r1.89)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeHashjoin.c.diff?r1=1.88&r2=1.89)
        nodeMergejoin.c (r1.86 -> r1.87)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeMergejoin.c.diff?r1=1.86&r2=1.87)
        nodeNestloop.c (r1.44 -> r1.45)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeNestloop.c.diff?r1=1.44&r2=1.45)
        nodeResult.c (r1.36 -> r1.37)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeResult.c.diff?r1=1.36&r2=1.37)
        nodeSubplan.c (r1.83 -> r1.84)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeSubplan.c.diff?r1=1.83&r2=1.84)
    pgsql/src/include/executor:
        executor.h (r1.134 -> r1.135)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/executor.h.diff?r1=1.134&r2=1.135)

pgsql-committers by date

Next:From: Tom LaneDate: 2007-02-02 00:07:28
Subject: pgsql: Repair failure to check that a table is still compatible with a
Previous:From: Tom LaneDate: 2007-02-02 00:04:17
Subject: pgsql: Repair insufficiently careful type checking for SQL-language

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group