database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-03 09:13:20 +03:00
Code Activity

Remove typmod checking from the recent security-related patches. It turns

Browse Source 
out that ExecEvalVar and friends don't necessarily have access to a tuple
descriptor with correct typmod: it definitely can contain -1, and possibly
might contain other values that are different from the Var's value.
Arguably this should be cleaned up someday, but it's not a simple change,
and in any case typmod discrepancies don't pose a security hazard.
Per reports from numerous people :-(

I'm not entirely sure whether the failure can occur in 8.0 --- the simple
test cases reported so far don't trigger it there.  But back-patch the
change all the way anyway.
This commit is contained in:
Tom Lane
2007-02-06 17:35:34 +00:00
parent 7fd912e854
commit c60125a9be
2 changed files with 11 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
src/backend/executor/execQual.c
View File

@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.183.2.5 2007/02/02 00:07:44 tgl Exp $
* $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.183.2.6 2007/02/06 17:35:34 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -497,8 +497,11 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext,
* Note: we allow a reference to a dropped attribute. slot_getattr
* will force a NULL result in such cases.
*
* Note: we check typmod, but allow the case that the Var has
* unspecified typmod while the column has a specific typmod.
* Note: ideally we'd check typmod as well as typid, but that seems
* impractical at the moment: in many cases the tupdesc will have
* been generated by ExecTypeFromTL(), and that can't guarantee to
* generate an accurate typmod in all cases, because some expression
* node types don't carry typmod.
*/
if (attnum > 0)
{
@@ -514,9 +517,7 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext,
/* can't check type if dropped, since atttypid is probably 0 */
if (!attr->attisdropped)
{
if (variable->vartype != attr->atttypid ||
(variable->vartypmod != attr->atttypmod &&
variable->vartypmod != -1))
if (variable->vartype != attr->atttypid)
ereport(ERROR,
(errmsg("attribute %d has wrong type", attnum),
errdetail("Table has type %s, but query expects %s.",
@@ -2871,9 +2872,8 @@ ExecEvalFieldSelect(FieldSelectState *fstate,
}
/* Check for type mismatch --- possible after ALTER COLUMN TYPE? */
if (fselect->resulttype != attr->atttypid ||
(fselect->resulttypmod != attr->atttypmod &&
fselect->resulttypmod != -1))
/* As in ExecEvalVar, we should but can't check typmod */
if (fselect->resulttype != attr->atttypid)
ereport(ERROR,
(errmsg("attribute %d has wrong type", fieldnum),
errdetail("Table has type %s, but query expects %s.",

7
src/backend/executor/execUtils.c
View File

@@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/executor/execUtils.c,v 1.126.2.4 2007/02/02 00:07:44 tgl Exp $
* $PostgreSQL: pgsql/src/backend/executor/execUtils.c,v 1.126.2.5 2007/02/06 17:35:34 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -537,10 +537,7 @@ ExecBuildProjectionInfo(List *targetList,
break;
}
attr = inputDesc->attrs[variable->varattno - 1];
if (attr->attisdropped ||
variable->vartype != attr->atttypid ||
(variable->vartypmod != attr->atttypmod &&
variable->vartypmod != -1))
if (attr->attisdropped || variable->vartype != attr->atttypid)
{
isVarList = false;
break;