The CVE-2018-1058 documentation change, commit 5770172, directed readers to
secure their schema usage patterns. That made secure their use of unqualified
function and operator names. Sometimes one wishes to call an object outside
search_path via a qualified name. That has its own security considerations,
which we hadn't documented to the same degree. The security team discussed
this and concluded that the lack of documentation did not itself constitute a
security flaw. I did prepare the attached patch, which Jonathan Katz
reviewed. I'm posting it here in case anyone else wishes to review it.
Thanks,
nm
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index b456698..07cd716 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -2380,9 +2380,12 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
using ALTER ROLE user SET
search_path = "$user". Everyone retains the ability to
create objects in the public schema, but only qualified names will
- choose those objects. A user holding the CREATEROLE
- privilege can undo this setting and issue arbitrary queries under the
- identity of users relying on the setting. If you
+ choose those objects. While qualified table references are fine, calls
+ to functions in the public schema will be
+ unsafe or unreliable. Also, a user holding
+ the CREATEROLE privilege can undo this setting and
+ issue arbitrary queries under the identity of users relying on the
+ setting. If you create functions or extensions in the public schema or
grant CREATEROLE to users not warranting this
almost-superuser ability, use the first pattern instead.
@@ -2393,8 +2396,10 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
Remove the public schema from search_path in
postgresql.conf.
The ensuing user experience matches the previous pattern. In addition
- to that pattern's implications for CREATEROLE, this
- trusts database owners the same way. If you assign
+ to that pattern's implications for functions
+ and CREATEROLE, this trusts database owners
+ like CREATEROLE. If you create functions or
+ extensions in the public schema or assign
the CREATEROLE
privilege, CREATEDB privilege or individual database
ownership to users not warranting almost-superuser access, use the
diff --git a/doc/src/sgml/ref/create_function.sgml
b/doc/src/sgml/ref/create_function.sgml
index c0adb8c..06be04e 100644
--- a/doc/src/sgml/ref/create_function.sgml
+++ b/doc/src/sgml/ref/create_function.sgml
@@ -545,8 +545,11 @@ CREATE [ OR REPLACE ] FUNCTION
as for the command. The string
link_symbol is the
function's link symbol, that is, the name of the function in the C
- language source code. If the link symbol is omitted, it is assumed
- to be the same as the name of the SQL function being defined.
+ language source code. If the link symbol is omitted, it is assumed to
+ be the same as the name of the SQL function being defined. The C names
+ of all functions must be different, so you must give overloaded C
+ functions different C names (for example, use the argument types as
+ part of the C names).
@@ -575,10 +578,9 @@ CREATE [ OR REPLACE ] FUNCTION
PostgreSQL allows function
overloading; that is, the same name can be
used for several different functions so long as they have distinct
-input argument types. However, the C names of all functions must be
-different, so you must give overloaded C functions different C
-names (for example, use the argument types as part of the C
-names).
+input argument types. Whether or not you use it, this capability entails
+security precautions when calling functions in databases where some users
+mistrust other users; see .
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 018118f..86869bd 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -1519,6 +1519,12 @@ sqrt(2)
+When issuing queries in a database where some users mistrust other users,
+observe security precautions from when
+writing function calls.
+
+
+
The arguments can optionally have names attached.
See for details.
@@ -2590,6 +2596,8 @@ SELECT CASE WHEN min(employees) > 0
its argument values in the same order as they are defined in the function
declaration. In named notation, the arguments are matched to the
function parameters by name and can be written in any order.
+For each notation, also consider the effect of function argument types,
+documented in .
diff --git a/doc/src/sgml/typeconv.sgml b/doc/src/sgml/typeconv.sgml
index ed4be4f..81dba7d 100644
--- a/doc/src/sgml/typeconv.sgml
+++ b/doc/src/sgml/typeconv.sgml
@@ -246,7 +246,19 @@ search path p
