Re: Facility for detecting insecure object naming

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Facility for detecting insecure object naming
Date: 2018-08-15 19:17:22
Message-ID: 20180815191722.GB4976@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)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(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 +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-08-15 19:18:57 Re: C99 compliance for src/port/snprintf.c
Previous Message Jeff Davis 2018-08-15 19:04:12 questions about the logical decoding implementation