| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Hannu Krosing <hannuk(at)google(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Pang <robertpang(at)google(dot)com> |
| Subject: | Re: Hardening PostgreSQL via (optional) ban on local file system access |
| Date: | 2022-06-25 00:08:17 |
| Message-ID: | CAKFQuwbYaDp2Hv0TA-FJ23Hh+dSYrhdA8BUEPXMwHRmCMC2ZKA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Friday, June 24, 2022, Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
> On Fri, Jun 24, 2022 at 4:13 PM Andres Freund <andres(at)anarazel(dot)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 at least ask the question, with full DBA control and no known bad
consequences.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2022-06-25 00:17:55 | Re: Hardening PostgreSQL via (optional) ban on local file system access |
| Previous Message | Hannu Krosing | 2022-06-24 23:59:35 | Re: Hardening PostgreSQL via (optional) ban on local file system access |