Re: Facility for detecting insecure object naming

Поиск
Список
Период
Сортировка
От Chapman Flack
Тема Re: Facility for detecting insecure object naming
Дата
Msg-id 5B7639CD.6090807@anastigmatix.net
обсуждение исходный текст
Ответ на Re: Facility for detecting insecure object naming  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Facility for detecting insecure object naming
Список pgsql-hackers
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.

Then there's room for bikeshedding on just where those unstacks/restacks
happen. I would think at clearly defined places in the core code, so as
to be independent of any PL. Any execution of command/query through SPI ?
Any function call through fmgr?

Emulating lexical scoping through dynamic means will have an overhead.
The usual use case would not involve a SET LEXICAL command issued on
its own, but such a command bound into a function declaration, as the
current SET commands can be. /Some/ PLs may be amenable to a static
analysis able to determine what objects are referred to in the code
and bind those ahead of time. Maybe, like the lanvalidator entry in
pg_language, there could be a lanprebind function, for those PLs
where that's tractable, and it would be called when the function is
created with any "lexically" bound variables. Record with each function
whether lanprebind returned success; if it did, skip the dynamic variable
futzing around calls to that function.

If the PL has no lanprebind function, or if it returned no-can-do for
a particular function and set of lexical settings, then the dynamic
emulation steps in.

Sounds a bit elaborate, but as it happens, there are further reasons
it could be good to have such "lexical" settings. There are some called
for in the SQL standard, for example. [1]

-Chap

[1] https://www.postgresql.org/message-id/5AAEAE0F.20006%40anastigmatix.net


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fix help option of contrib/oid2name
Следующее
От: Yugo Nagata
Дата:
Сообщение: Re: has_table_privilege for a table in unprivileged schema causesan error