On Mon, 2024-03-04 at 21:15 -0500, Tom Lane wrote:
> Jeff Davis writes:
> > Fix search_path to a safe value during maintenance operations.
>
> The buildfarm seems pretty unhappy with this.
Looks like I need to use GUC_ACTION_SAVE. I will remedy it shortly.
Regards,
Jeff Davis
Jeff Davis writes:
> Fix search_path to a safe value during maintenance operations.
The buildfarm seems pretty unhappy with this.
regards, tom lane
Fix search_path to a safe value during maintenance operations.
While executing maintenance operations (ANALYZE, CLUSTER, REFRESH
MATERIALIZED VIEW, REINDEX, or VACUUM), set search_path to
'pg_catalog, pg_temp' to prevent inconsistent behavior.
Functions that are used for functional indexes, in in
On Mon, 2023-06-19 at 16:03 -0400, Robert Haas wrote:
> I'm inclined to think that this is a real security issue and am not
Can you expand on that a bit? You mean a practical security issue for
the intended use cases?
> very sanguine about waiting another year to fix it, but at the same
> time, I
On Thu, Jun 15, 2023 at 12:59 AM Jeff Davis wrote:
> On Tue, 2023-06-13 at 16:23 -0400, Tom Lane wrote:
> > What I'm concerned about is making such a fundamental semantics
> > change
> > post-beta1.
>
> I have added the patch to the July CF for v17.
>
> If someone does feel like something should b
On Tue, 2023-06-13 at 16:23 -0400, Tom Lane wrote:
> What I'm concerned about is making such a fundamental semantics
> change
> post-beta1.
I have added the patch to the July CF for v17.
If someone does feel like something should be done for v16, David G.
Johnston posted one possibility here:
ht
Jeff Davis writes:
> The most objection seems to be expressed most succinctly in this
> message:
> https://www.postgresql.org/message-id/16134.1456767564%40sss.pgh.pa.us
> "if we allow non-owners to run ANALYZE, they'd be able to mess things
> up by setting the stats target either much lower or mu
On Tue, Jun 13, 2023 at 1:55 PM Jeff Davis wrote:
> Perhaps the objections in that thread were because the proposal
> involved inferring the privilege to ANALYZE from other privileges,
> rather than having an explicit MAINTAIN privilege?
>
>
That is true; but it seems worth being explicit whether
On Tue, 2023-06-13 at 13:22 -0700, David G. Johnston wrote:
> This is the specific (first?) message I am recalling.
>
> https://www.postgresql.org/message-id/A737B7A37273E048B164557ADEF4A58B53803F5A%40ntex2010i.host.magwien.gv.at
The most objection seems to be expressed most succinctly in this
me
Noah Misch writes:
> Best argument for shipping without $SUBJECT: we already have REFERENCES and
> TRIGGER privilege that tend to let the grantee hijack the table owner's
> account. Adding MAINTAIN to the list, while sad, is defensible. I still
> prefer to ship with $SUBJECT, not without.
What
On Tue, Jun 13, 2023 at 12:54 PM Jeff Davis wrote:
> On Mon, 2023-06-12 at 18:31 -0700, David G. Johnston wrote:
> > On a related note, are we OK with someone using this privilege
> > setting their own default_statistics_target?
> >
> >
> https://www.postgresql.org/docs/current/runtime-config-que
On Mon, 2023-06-12 at 18:31 -0700, David G. Johnston wrote:
> On a related note, are we OK with someone using this privilege
> setting their own default_statistics_target?
>
> https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET
>
> My prior attempt to o
On Tue, 2023-06-13 at 11:24 -0400, Robert Haas wrote:
> Interesting. The issue of "what is a safe search path?" is more
> nuanced than I would prefer. :-(
As far as I can tell, search_path was designed as a convenience for
interactive queries, where a lot of these nuances make sense. But they
don'
On Mon, 2023-06-12 at 17:50 -0700, David G. Johnston wrote:
> Only change the search_path if someone other than the table owner or
> superuser is running the command (which should only be possible via
> the new MAINTAIN privilege)?
That sounds like a reasonable compromise, but a bit messy. If we d
On Mon, Jun 12, 2023 at 05:39:40PM -0700, Jeff Davis wrote:
> On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote:
> > The timing was not great, but this is fixing a purported defect in an
> > older
> > v16 feature. If the MAINTAIN privilege is actually fine, we're all
> > set for
> > v16. If MAI
On Mon, Jun 12, 2023 at 8:20 PM Jeff Davis wrote:
> I followed the rules here for "Writing SECURITY DEFINER Functions
> Safely":
>
> https://www.postgresql.org/docs/16/sql-createfunction.html
>
> which suggests adding pg_temp at the end (otherwise it is searched
> first by default).
Interesting.
On Monday, June 12, 2023, David G. Johnston
wrote:
> On Mon, Jun 12, 2023 at 5:40 PM Jeff Davis wrote:
>
>> On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote:
>> > The timing was not great, but this is fixing a purported defect in an
>> > older
>> > v16 feature. If the MAINTAIN privilege is a
On Mon, Jun 12, 2023 at 5:40 PM Jeff Davis wrote:
> On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote:
> > The timing was not great, but this is fixing a purported defect in an
> > older
> > v16 feature. If the MAINTAIN privilege is actually fine, we're all
> > set for
> > v16. If MAINTAIN do
On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote:
> The timing was not great, but this is fixing a purported defect in an
> older
> v16 feature. If the MAINTAIN privilege is actually fine, we're all
> set for
> v16. If MAINTAIN does have a material problem that $SUBJECT had
> fixed, we
> shoul
On Mon, 2023-06-12 at 13:33 -0400, Robert Haas wrote:
> I wonder why this commit used pg_catalog, pg_temp rather than just
> the
> empty string, as AutoVacWorkerMain does.
I followed the rules here for "Writing SECURITY DEFINER Functions
Safely":
https://www.postgresql.org/docs/16/sql-createfunct
On Mon, Jun 12, 2023 at 1:05 PM Noah Misch wrote:
> > I concur with the upthread objection that it is way too late in
> > the release cycle to be introducing a breaking change like this.
> > I request that you revert it.
>
> The timing was not great, but this is fixing a purported defect in an old
On Sat, Jun 10, 2023 at 01:33:31AM -0400, Tom Lane wrote:
> Jeff Davis writes:
> > Attached a patch to mark those functions as PARALLEL UNSAFE, which
> > fixes the problem.
>
> > Alternatively, I could just take out that line, as those SQL functions
> > are not controlled by the MAINTAIN privileg
Jeff Davis writes:
> Attached a patch to mark those functions as PARALLEL UNSAFE, which
> fixes the problem.
> Alternatively, I could just take out that line, as those SQL functions
> are not controlled by the MAINTAIN privilege. But for consistency I
> think it's a good idea to leave it in so th
On Fri, 2023-06-09 at 17:37 -0700, Jeff Davis wrote:
> Attached a patch to mark those functions as PARALLEL UNSAFE, which
> fixes the problem.
On second thought, that might not be acceptable for amcheck, depending
on how its run.
I think it's OK if run by pg_amcheck, because that runs it on a sin
On Fri, 2023-06-09 at 15:16 -0700, Jeff Davis wrote:
> On Fri, 2023-06-09 at 20:54 +, Jeff Davis wrote:
> > Fix search_path to a safe value during maintenance operations.
>
> Looks like this is causing pg_amcheck failures in the buildfarm.
> Investigating...
It looks related to bt_index_check
On Fri, 2023-06-09 at 20:54 +, Jeff Davis wrote:
> Fix search_path to a safe value during maintenance operations.
Looks like this is causing pg_amcheck failures in the buildfarm.
Investigating...
Regards,
Jeff Davis
Fix search_path to a safe value during maintenance operations.
While executing maintenance operations (ANALYZE, CLUSTER, REFRESH
MATERIALIZED VIEW, REINDEX, or VACUUM), set search_path to
'pg_catalog, pg_temp' to prevent inconsistent behavior.
Functions that are used for functional indexes, in in
27 matches
Mail list logo
