Re: Hardening PostgreSQL via (optional) ban on local file system access - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Hardening PostgreSQL via (optional) ban on local file system access
Date
Msg-id CAMT0RQR3SBiGWP=JsnQvXqWYcTR7o1zuRd8JPfWQvv6buwRd9g@mail.gmail.com
Whole thread Raw
In response to Re: Hardening PostgreSQL via (optional) ban on local file system access  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
The old versions should definitely not have it turned on by default. I
probably was not as clear as I thought in bringing out that point..

For upcoming next ones the distributors may want to turn it on for
some more security-conscious ("enterprize") distributions.

-- Hannu

On Sat, Jun 25, 2022 at 2:08 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
>
>
> On Friday, June 24, 2022, Gurjeet Singh <gurjeet@singh.im> wrote:
>>
>> On Fri, Jun 24, 2022 at 4:13 PM Andres Freund <andres@anarazel.de> wrote:
>> > On 2022-06-25 00:08:13 +0200, Hannu Krosing wrote:
>>
>> > > 3) should this be back-patched (we can provide batches for all
>> > > supported PgSQL versions)
>> >
>> > Err, what?
>>
>> Translation: Backpatching these changes to any stable versions will
>> not be acceptable (per the project versioning policy [1]), since these
>> changes would be considered new feature. These changes can break
>> installations, if released in a minor version.
>>
>
> No longer having the public schema in the search_path was a feature that got back-patched, with known bad
consequences,without any way for the DBA to voice their opinion on the matter.  This proposal seems similar enough to
atleast ask the question, with full DBA control and no known bad consequences. 
>
> David J.
>



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Hardening PostgreSQL via (optional) ban on local file system access
Next
From: Andres Freund
Date:
Subject: Re: [PATCH] Optimize json_lex_string by batching character copying