Tatsuo Ishii [EMAIL PROTECTED] writes:
I looked into this more and I think I'm afraid the proposed solution
actually does not work for SQL functions. For example,
CREATE OR REPLACE FUNCTION foo(INTEGER, INTEGER) RETURNS INTEGER AS $$
SET search_path To pg_catalog,public;
SELECT mod($1,$2);
$$ LANGUAGE sql SECURITY DEFINER;
If an attacker creates public.mod() to do something bad and override
his search_path to public,pg_catalog before executing foo(), his
attack will succeed since calling to mod() is resolved in the plan
time thus it will be resolved to public.mod, rather than
pg_catalog.mod.
True, because the SQL-function code runs parse analysis for the whole
function body before executing any of it. We could fix it by doing
parse-analyze/plan/execute one statement at a time, which would make
SQL functions work more like multi-statement strings submitted by a
client application. Just a day or two ago there was someone complaining
that they couldn't create and use a temp table in the same SQL function,
due to this same behavior; and I recall similar gripes in the past.
Maybe it's time to change it.
regards, tom lane
Ok. So bottom line would be do not use SECURITY DEFINER SQL functions
unless you make every object including functions and operators into
schema-qualified one.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
