Re: Facility for detecting insecure object naming

On Tue, Aug 14, 2018 at 03:00:55PM +0000, Robert Haas wrote:
> The more I think about it, the more I think having a way to set a
> lexically-scoped search path is probably the answer. Many years ago,
> Perl had only "local" as a way of declaring local variables, which
> used dynamic scoping, and then they invented "my", which uses lexical
> scoping, and everybody abandoned "local" and started using "my,"
> because otherwise a reference to a variable inside a procedure may
> happen to refer to a local variable further up the call stack rather
> than a global variable if the names happen to collide. It turns out
> that not knowing to which object a reference will refer is awful, and
> you should avoid it like the plague. This is exactly the same problem
> we have with search_path. People define functions -- or index
> expressions -- assuming that the function and operator references will
> refer to the same thing at execution time that they do at definition
> time.
>
> That is, I think, an entirely *reasonable* expectation. Basically all
> programming languages work that way. If you could call a C function
> in such a way that the meaning of identifiers that appeared there was
> dependent on some piece of state inherited from the caller's context
> rather than from the declarations visible at the time that the C
> function was compiled, it would be utter and complete chaos. It would
> in fact greatly resemble the present state of affairs in PostgreSQL,
> where making your code reliably mean what you intended requires either
> forcing the search path everywhere or schema-qualifying the living
> daylights out of everything. I think we should try to follow Perl's
> example, acknowledge that we basically got this wrong on the first
> try, and invent something new that works better.

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. I am unclear
how lexical scoping helps with this, or with Postgres.

With Postgres you are effectively adding functions into the executable
that didn't exist at link time, and potentially replacing compiled-in
functions with others that might match the call site better.

--
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 +