Re: Hardening PostgreSQL via (optional) ban on local file system access
От | Hannu Krosing |
---|---|
Тема | Re: Hardening PostgreSQL via (optional) ban on local file system access |
Дата | |
Msg-id | CAMT0RQR3SBiGWP=JsnQvXqWYcTR7o1zuRd8JPfWQvv6buwRd9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hardening PostgreSQL via (optional) ban on local file system access ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | 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 по дате отправления: