Re: Facility for detecting insecure object naming - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Facility for detecting insecure object naming
Date
Msg-id 20180815191722.GB4976@momjian.us
Whole thread Raw
In response to Re: Facility for detecting insecure object naming  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Facility for detecting insecure object naming
List pgsql-hackers
On Wed, Aug 15, 2018 at 11:05:06AM -0400, Robert Haas wrote:
> On Tue, Aug 14, 2018 at 4:42 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > So you are saying PG functions should lock down their search path at
> > function definition time, and use that for all function invocations?
> 
> Yes, mostly.  I don't think we can just change the existing behavior;
> it would break a catastrophic amount of stuff.  But we could add an
> optional feature that does this, and encourage people to use it, much
> the way Perl continues to support "local" even though "my" has been a
> best practice for several decades.

So each function defines its search_path, and each function you call sets
its own search_path, basically?  That is what you mean by lexical scope?
I think if this approach was fully secure, it would get more traction.

We can't lock down the called objects at function definition time since
the languages aren't necessarily parsed at that time, and some objects
might not exist yet, right?  It might be interesting to record a list of
objects and their owners at function definition time and check that
somehow at function execution time.

In relation to your "break a catastrophic amount of stuff," I assume if
we have a trust_users GUC, users would be more willing to have expansive
search_path values because security concerns would be lessened.

-- 
  Bruce Momjian  <bruce@momjian.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 +


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: questions about the logical decoding implementation
Next
From: Tom Lane
Date:
Subject: Re: C99 compliance for src/port/snprintf.c