Re: Facility for detecting insecure object naming

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Facility for detecting insecure object naming
Дата
Msg-id 20180815191722.GB4976@momjian.us
обсуждение исходный текст
Ответ на Re: Facility for detecting insecure object naming  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Facility for detecting insecure object naming
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: questions about the logical decoding implementation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: C99 compliance for src/port/snprintf.c