Horton

Re: MAINTAIN privilege -- what do we need to un-revert it?

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Michael Paquier <michael@paquier.xyz>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org, Joe Conway <mail@joeconway.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2024-07-13T21:47:48Z
Lists: pgsql-hackers 
On Fri, Jul 12, 2024 at 04:50:17PM -0700, Jeff Davis wrote:
> On Fri, 2024-07-12 at 16:11 -0700, Noah Misch wrote:
> > Since refresh->relation is a RangeVar, this departs from the standard
> > against
> > repeated name lookups, from CVE-2014-0062 (commit 5f17304).
> 
> Interesting, thank you.
> 
> I did a rough refactor and attached v3. Aside from cleanup issues, is
> this what you had in mind?

> +extern ObjectAddress RefreshMatViewByOid(Oid matviewOid, bool skipData, bool concurrent,
> +										 const char *queryString, ParamListInfo params,
> +										 QueryCompletion *qc);
>  

Yes, that's an API design that avoids repeated name lookups.

Commits

  1. doc: Note that CREATE MATERIALIZED VIEW restricts search_path.

  2. Small refactoring around ExecCreateTableAs().

  3. Add is_create parameter to RefreshMatviewByOid().

  4. Remove unused ParamListInfo argument from ExecRefreshMatView.

  5. When creating materialized views, use REFRESH to load data.

  6. Add missing RestrictSearchPath() calls.

  7. Fix search_path to a safe value during maintenance operations.

  8. Revert MAINTAIN privilege and pg_maintain predefined role.

  9. Avoid repeated name lookups during table and index DDL.

  10. Add a materialized view relations.