Re: Facility for detecting insecure object naming

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: Facility for detecting insecure object naming
Дата
Msg-id CAMsGm5eaD06esdYFYdT15wJeGPSio29GjM0vd4vXss+Nw=zT-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Facility for detecting insecure object naming  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Facility for detecting insecure object naming
Список pgsql-hackers
Дерево обсуждения
On 8 August 2018 at 09:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:

When the security team was discussing this issue before, we speculated
about ideas like inventing a function trust mechanism, so that attacks
based on search path manipulations would fail even if they managed to
capture an operator reference.  I'd rather go down that path than
encourage people to do more schema qualification.


I must be missing something. Aren't search_path manipulation problems avoided by using "SET search_path FROM CURRENT"?

While I'm asking, does anybody know why this isn't the default, especially for SECURITY DEFINER functions? It seems like in addition to being a more secure default, it would be better for JIT compilation - right now it seems you need to re-compile whenever the function is called with a different search_path. The ability for a function's meaning to change dramatically depending on the caller's search_path seems like an occasionally-useful extra, not what one would expect as the default.

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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: Standby trying "restore_command" before local WAL
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Temporary tables prevent autovacuum, leading to XID wraparound