diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2012-05-30 23:28:21 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2012-05-30 23:28:21 -0400 |
| commit | af6ee5e8d4d3b8623e1e8309d10d77d0dd8a5297 (patch) | |
| tree | 563ab98bcdf9d05faa8784f420c99e45eac1d703 | |
| parent | f5c5e7497b6057151936313d0cdb6cc8dc159331 (diff) | |
| download | postgresql-af6ee5e8d4d3b8623e1e8309d10d77d0dd8a5297.tar.gz postgresql-af6ee5e8d4d3b8623e1e8309d10d77d0dd8a5297.zip | |
Ignore SECURITY DEFINER and SET attributes for a PL's call handler.
It's not very sensible to set such attributes on a handler function;
but if one were to do so, fmgr.c went into infinite recursion because
it would call fmgr_security_definer instead of the handler function proper.
There is no way for fmgr_security_definer to know that it ought to call the
handler and not the original function referenced by the FmgrInfo's fn_oid,
so it tries to do the latter, causing the whole process to start over
again.
Ordinarily such misconfiguration of a procedural language's handler could
be written off as superuser error. However, because we allow non-superuser
database owners to create procedural languages and the handler for such a
language becomes owned by the database owner, it is possible for a database
owner to crash the backend, which ideally shouldn't be possible without
superuser privileges. In 9.2 and up we will adjust things so that the
handler functions are always owned by superusers, but in existing branches
this is a minor security fix.
Problem noted by Noah Misch (after several of us had failed to detect
it :-(). This is CVE-2012-2655.
| -rw-r--r-- | src/backend/utils/fmgr/fmgr.c | 14 |
1 files changed, 10 insertions, 4 deletions
diff --git a/src/backend/utils/fmgr/fmgr.c b/src/backend/utils/fmgr/fmgr.c index 308d7a0a239..00711a6f86c 100644 --- a/src/backend/utils/fmgr/fmgr.c +++ b/src/backend/utils/fmgr/fmgr.c @@ -153,7 +153,7 @@ fmgr_lookupByName(const char *name) void fmgr_info(Oid functionId, FmgrInfo *finfo) { - fmgr_info_cxt(functionId, finfo, CurrentMemoryContext); + fmgr_info_cxt_security(functionId, finfo, CurrentMemoryContext, false); } /* @@ -168,7 +168,7 @@ fmgr_info_cxt(Oid functionId, FmgrInfo *finfo, MemoryContext mcxt) /* * This one does the actual work. ignore_security is ordinarily false - * but is set to true by fmgr_security_definer to avoid recursion. + * but is set to true when we need to avoid recursion. */ static void fmgr_info_cxt_security(Oid functionId, FmgrInfo *finfo, MemoryContext mcxt, @@ -220,7 +220,7 @@ fmgr_info_cxt_security(Oid functionId, FmgrInfo *finfo, MemoryContext mcxt, /* * If it has prosecdef set, or non-null proconfig, use * fmgr_security_definer call handler --- unless we are being called again - * by fmgr_security_definer. + * by fmgr_security_definer or fmgr_info_other_lang. * * When using fmgr_security_definer, function stats tracking is always * disabled at the outer level, and instead we set the flag properly in @@ -403,7 +403,13 @@ fmgr_info_other_lang(Oid functionId, FmgrInfo *finfo, HeapTuple procedureTuple) elog(ERROR, "cache lookup failed for language %u", language); languageStruct = (Form_pg_language) GETSTRUCT(languageTuple); - fmgr_info(languageStruct->lanplcallfoid, &plfinfo); + /* + * Look up the language's call handler function, ignoring any attributes + * that would normally cause insertion of fmgr_security_definer. We + * need to get back a bare pointer to the actual C-language function. + */ + fmgr_info_cxt_security(languageStruct->lanplcallfoid, &plfinfo, + CurrentMemoryContext, true); finfo->fn_addr = plfinfo.fn_addr; /* |