Re: security_definer_search_path GUC

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: security_definer_search_path GUC
Дата
Msg-id CAFj8pRBJe=EFfqzcwFkR_9urHxL-wLy2OgjA6n3W1HWzs0NEfQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: security_definer_search_path GUC  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: security_definer_search_path GUC  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список pgsql-hackers


čt 3. 6. 2021 v 17:54 odesílatel Marko Tiikkaja <marko@joh.to> napsal:
On Thu, Jun 3, 2021 at 9:14 AM Joel Jacobson <joel@compiler.org> wrote:
On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote:
They still show up everywhere when looking at "public".  So this is only slightly better, and a maintenance burden.

Good point. I find this annoying as well sometimes.

It's easy to get a list of all objects for an extension, via \dx+

But it's hard to see what objects in a schema, that are provided by different extensions, via e.g. \df public.*

What about adding a new "Extension" column next to "Schema" to the relevant commands, such as \df? 

That's just one part of it.  The other part of my original proposal was to avoid having to  SET search_path  for all SECURITY DEFINER functions.  I still think either being able to lock search_path or the separate prosecdef search_path is the best option here.

I agree so some possibility of locking search_path or possibility to control who and when can change it can increase security. This should be a core feature. It's maybe more generic issue - same functionality can be required for work_mem setting, maybe max_paralel_workers_per_gather, and other GUC

Regards

Pavel


.m

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

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: security_definer_search_path GUC
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?