Re: Facility for detecting insecure object naming

On Tue, Aug 14, 2018 at 04:23:33PM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Well, in C, if the calling function is not in the current C file, you
> > really don't know what function you are linking to --- it depends on
> > what other object files are linked into the executable.
>
> True.
>
> > I am unclear how lexical scoping helps with this, or with Postgres.
>
> Well, if you say sqrt(x) in C, and you don't have sqrt or x defined in
> the current function, you know that you're going to call a global
> function called sqrt and pass to it a global variable called x.
> You're not going to latch onto a local variable called x in the
> function that called your function, and if the calling function has a
> local variable called sqrt, that doesn't matter either. The linker
> can point every called to sqrt() in the program at a different place
> than expected, but you can't monkey with the behavior of an individual
> call by having the calling function declare identifiers that mask the
> ones the function intended to reference.

What we are doing is more like C++ virtual functions, where the class
calling it can replace function calls in subfunctions:

https://www.geeksforgeeks.org/virtual-function-cpp/

> On the other hand, when you call an SQL-language function, or even to
> some extent a plpgsql-language function, from PostgreSQL, you can in
> fact change the meanings of every identifier that appears in that
> function body unless those references are all schema-qualified or the
> function sets the search path. If an SQL-language function calls

I think we decide that search path alone for functions is insufficient
because of data type matching, unless the schema is secure.

> sqrt(x), you can set the search_path to some schema you've created
> where there is a completely different sqrt() function than that
> function intended to call. That is a very good way to make stuff (a)
> break or (b) be insecure.
>
> The point of having a lexically-scoped search path is that it is
> generally the case that when you write SQL code, you know the search
> path under which you want it to execute. You can get that behavior
> today by attaching a SET clause to the function, but that defeats
> inlining, is slower, and the search path you configure applies not
> only to the code to which is attached but to any code which it in turn
> calls. In other words, the search path setting which you configure
> has dynamic scope. I submit that's bad. Functions can reasonably be
> expected to know the search path that should be used to run the code
> they actually contain, but they cannot and should not need to know the
> search path that should be used to run code in other functions which
> they happen to call.

So you are saying PG functions should lock down their search path at
function definition time, and use that for all function invocations?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +