Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit a8c3f16

Browse files
committed
Remove typmod checking from the recent security-related patches. It turns
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.
1 parent 869585c commit a8c3f16

File tree

2 files changed

+11
-14
lines changed

2 files changed

+11
-14
lines changed

src/backend/executor/execQual.c

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.212 2007/02/03 14:06:53 petere Exp $
11+
* $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.213 2007/02/06 17:35:20 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -488,8 +488,11 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext,
488488
* Note: we allow a reference to a dropped attribute. slot_getattr
489489
* will force a NULL result in such cases.
490490
*
491-
* Note: we check typmod, but allow the case that the Var has
492-
* unspecified typmod while the column has a specific typmod.
491+
* Note: ideally we'd check typmod as well as typid, but that seems
492+
* impractical at the moment: in many cases the tupdesc will have
493+
* been generated by ExecTypeFromTL(), and that can't guarantee to
494+
* generate an accurate typmod in all cases, because some expression
495+
* node types don't carry typmod.
493496
*/
494497
if (attnum > 0)
495498
{
@@ -505,9 +508,7 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext,
505508
/* can't check type if dropped, since atttypid is probably 0 */
506509
if (!attr->attisdropped)
507510
{
508-
if (variable->vartype != attr->atttypid ||
509-
(variable->vartypmod != attr->atttypmod &&
510-
variable->vartypmod != -1))
511+
if (variable->vartype != attr->atttypid)
511512
ereport(ERROR,
512513
(errmsg("attribute %d has wrong type", attnum),
513514
errdetail("Table has type %s, but query expects %s.",
@@ -3362,9 +3363,8 @@ ExecEvalFieldSelect(FieldSelectState *fstate,
33623363
}
33633364

33643365
/* Check for type mismatch --- possible after ALTER COLUMN TYPE? */
3365-
if (fselect->resulttype != attr->atttypid ||
3366-
(fselect->resulttypmod != attr->atttypmod &&
3367-
fselect->resulttypmod != -1))
3366+
/* As in ExecEvalVar, we should but can't check typmod */
3367+
if (fselect->resulttype != attr->atttypid)
33683368
ereport(ERROR,
33693369
(errmsg("attribute %d has wrong type", fieldnum),
33703370
errdetail("Table has type %s, but query expects %s.",

src/backend/executor/execUtils.c

Lines changed: 2 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/executor/execUtils.c,v 1.143 2007/02/02 00:07:03 tgl Exp $
11+
* $PostgreSQL: pgsql/src/backend/executor/execUtils.c,v 1.144 2007/02/06 17:35:20 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -632,10 +632,7 @@ ExecBuildProjectionInfo(List *targetList,
632632
break;
633633
}
634634
attr = inputDesc->attrs[variable->varattno - 1];
635-
if (attr->attisdropped ||
636-
variable->vartype != attr->atttypid ||
637-
(variable->vartypmod != attr->atttypmod &&
638-
variable->vartypmod != -1))
635+
if (attr->attisdropped || variable->vartype != attr->atttypid)
639636
{
640637
isVarList = false;
641638
break;

0 commit comments

Comments
 (0)