Re: [HACKERS] search path security issue?

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] search path security issue?
Дата
Msg-id CABUevEyW218zto3TU0idqysJFknJ1bOyDuw7RXFo52eXf1k_2Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] search path security issue?  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: [HACKERS] search path security issue?  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers


On Fri, Oct 6, 2017 at 12:05 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
On 10/05/2017 02:54 PM, David G. Johnston wrote:
On Thu, Oct 5, 2017 at 2:37 PM, Joshua D. Drake <jd@commandprompt.com <mailto:jd@commandprompt.com>>wrote:

    I get being able to change my search_path on the fly but it seems
    odd that as user foo I can change my default search path?


Seems down-right thoughtful of us to allow users to change their own defaults instead of forcing them to always change things on-the-fly or bug a DBA to change the default for them.

It seems that if a super user changes the search path with ALTER USER/ROLE, then the user itself should not (assuming not an elevated privilege) should not be able to change it. Again, I get being able to do it with SET but a normal user shouldn't be able to reset a super user determined setting.

This is in no way specific to search_path.

It would be a nice feature to have in general, like a "basic guc permissions" thing. At least allowing a superuser to prevent exactly this. You could argue the same thing for example for memory parameters and such. We have no permissions at all when it comes to userset gucs today -- and of course, if something should be added about this, it should be done in a way that works for all the userset variables, not just search_path. 

--

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: [HACKERS] pgsql: Remove ICU tests from default run
Следующее
От: Nikolay Shaplov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Tests for reloptions