Re: [HACKERS] search path security issue?
От | David G. Johnston |
---|---|
Тема | Re: [HACKERS] search path security issue? |
Дата | |
Msg-id | CAKFQuwbdJ1PSoJy7=5CweuYtd4jzhKA6VLVLxCUo9t5Tc9kDsQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] search path security issue? ("Joshua D. Drake" <jd@commandprompt.com>) |
Список | pgsql-hackers |
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.
If the superuser really wanted to enforce it they could, a bit verbosely, set the default for the user for every database explicitly so that the database+role setting takes precedence over the role-only setting.
I get where you are coming from but there is no demonstrated security-related reason to enforce such a restriction and so adding the book-keeping necessary to track "who done it" (i.e. mere presence of a value is an insufficient distinguishing characteristic) has a cost but no benefit (if the superuser is upset that someone changed their own default search_path the fact that said user is entrusted with login credentials should be questioned).
David J.
В списке pgsql-hackers по дате отправления: