> It has come to the attention of the core team of the PostgreSQL project > that insecure programming practice is widespread in SECURITY DEFINER > functions. Many of these functions are exploitable in that they allow > users that have the privilege to execute such a function to execute > arbitrary code with the privileges of the owner of the function. > > The SECURITY DEFINER property of functions is a special non-default > property that causes such functions to be executed with the privileges > of their owner rather than with the privileges of the user invoking the > function (the default mode, SECURITY INVOKER). Thus, this mechanism is > very similar to the "setuid" mechanism in Unix operating systems. > > Because SQL object references in function code are resolved at run time, > any references to SQL objects that are not schema qualified are > resolved using the schema search path of the session at run time, which > is under the control of the calling user. By installing functions or > operators with appropriate signatures in other schemas, users can then > redirect any function or operator call in the function code to > implementations of their choice, which, in case of SECURITY DEFINER > functions, will still be executed with the function owner privileges. > Note that even seemingly innocent invocations of arithmetic operators > are affected by this issue, so it is likely that a large fraction of > all existing functions are exploitable. > > The proper fix for this problem is to insert explicit SET search_path > commands into each affected function to produce a known safe schema > search path. Note that using the default search path, which includes a > reference to the "$user" schema, is not safe when unqualified > references are intended to be found in the "public" schema and "$user" > schemas exist or can be created by other users. It is also not > recommended to rely on rigorously schema-qualifying all function and > operator invocations in function source texts, as such measures are > likely to induce mistakes and will furthermore make the source code > harder to read and maintain. But if we insert a set schema search_path command in an SQL function, the caller will be affected by it. Doing reset search_path before returning to caller might solve some of problems, but it will not recover caller's special search_path. How do you solve the problem? -- Tatsuo Ishii SRA OSS, Inc. Japan
