diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2007-02-06 17:35:41 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2007-02-06 17:35:41 +0000 |
| commit | 122680c51443b66fd9fc8687881ad571248516fa (patch) | |
| tree | da0238d079879ee568966e3debc6b22b90abf0e3 /src | |
| parent | 2d28b69000ea0f5f348d084eb86f9fcd1730c2e6 (diff) | |
| download | postgresql-122680c51443b66fd9fc8687881ad571248516fa.tar.gz postgresql-122680c51443b66fd9fc8687881ad571248516fa.zip | |
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.
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/executor/execQual.c | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c index be3e1c12188..865b8a6ab65 100644 --- a/src/backend/executor/execQual.c +++ b/src/backend/executor/execQual.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.171.4.3 2007/02/02 00:08:01 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.171.4.4 2007/02/06 17:35:41 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -502,8 +502,11 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext, * Note: we allow a reference to a dropped attribute, and force a * NULL result. This path is not fast. * - * 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) { @@ -529,9 +532,7 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext, return (Datum) 0; } - 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.", @@ -2856,9 +2857,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.", |