Re: Facility for detecting insecure object naming

On Thu, Aug 16, 2018 at 10:58:21PM -0400, Chapman Flack wrote:
> On 08/16/18 21:31, Bruce Momjian wrote:
>
> > I understand you don't like that a search_path changed by a function is
> > passed down to functions it calls, but what would you like the system to
> > use as a search path for called functions? The search path of the
> > session?
>
> This is beginning to sound like an exercise in /emulating/ lexical scoping
> in a system that can run bits of code supplied in many different PLs, not
> all of which can necessarily participate in "real" lexical scoping.
>
> It could look like another flavor of setting a GUC. There's SET SESSION,
> SET LOCAL, and maybe now SET LEXICAL. The key to the emulation is to
> temporarily unstack the SET LEXICAL when the function it "lexically"
> applies to makes calls to other functions. And restack it when those
> other functions return.

Right. My point is that people don't like dynamic scoping in Perl
because it overrides the lexical scoping implicit in the source code
structure. For Postgres objects, like functions, there is no implicit
scope --- each object is defined and managed on its own. So, the
problem isn't that dynamic scoping is overriding implicit scoping, but
that we only have dynamic scoping, and there is no implicit scoping to
override.

So, to move this forward, we have to have some way of defining implicit
scoping. It could be:

o other objects in the same schema
o owned by the same user
o a member of the same extension
o a SET search_path in the function
o the search_path at object creation time
o objects referenced at object creation time

(I guess Oracle's package syntax helps them here.) You have to define
some implicit scoping so you don't have to rely on dynamic scoping.

Two of Robert's problem cases were expression indexes that are later
reindexed, and calling an extension that wants to call functions from the
same extension, even if the search_path does not include the extension's
schema. So, which implicit scoping rules would fix those problems?

In addition, you have people adding, updating, and removing objects
while these functions are required to still run properly. That is
something that also doesn't typically happen in a Perl program, because
the source files or package APIs are assumed to be tightly managed.

Also, with Perl, you have a layer of objects, from built-in ones, to
packages, to application-level objects. With Postgres, they are all
thrown together into the same tables, and there is no filtering of
scopes.

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