Re: [HACKERS] search path security issue? - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] search path security issue?
Date
Msg-id CABUevEyW218zto3TU0idqysJFknJ1bOyDuw7RXFo52eXf1k_2Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] search path security issue?  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: [HACKERS] search path security issue?
List 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 by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] pgsql: Remove ICU tests from default run
Next
From: Nikolay Shaplov
Date:
Subject: Re: [HACKERS] [PATCH] Tests for reloptions