pg_ivm 1.5.1 (2023-03-02)

This release contains security fixes.

• Exposure of sensitive information to an unauthorized actor (CWE-200) - CVE-2023-22847
  An Incrementally Maintainable Materialized View (IMMV) created by pg_ivm may reflect rows with Row-Level Security that the owner of the IMMV should not have access to.

• Uncontrolled search path element (CWE-427) - CVE-2023-23554
  When refreshing an IMMV, pg_ivm executes functions without specifying schema names. Under certain conditions, pg_ivm may be tricked to execute unexpected functions from other schemas with the IMMV owner's privilege.

Bug fixes

• Fix row level security checks during view maintenance by @yugo-n (CVE-2023-22847)

  The view maintenance is performed under the view owner privilege. If a modified table has a (Row Level Security) RLS policy, rows in that table must be accessed by the privilege of the IMMV owner during view maintenance, so rows invisible to the view owner must not appear in the IMMV. However, the security check was not properly handled, and rows that must not be accessed from the view owner could appear in the view contents when the view was refreshed incrementally during a query that contains multiple types of commands, like a modifying CTE that contains INSERT and UPDATE, or a MERGE command.

• Fix to use qualified function names during maintenance by @yugo-n (CVE-2023-23554)

  Previously, functions names in pg_catalog schema that were used during view maintenance were not qualified. This is problematic because functions in other schema could be referenced unintentionally. Moreover, that could result in privilege escalation that if a nefarious user who can create a function, arbitrary functions could be executed under IMMV owner's privilege.

• Rebuild the query for recalculating min/max after search_path change by @yugo-n (CVE-2023-23554)

  Cached plans for recalculating min/max values are built from the view definition query text. Therefore, when the search_path was changed, the query text was analyzed again, and tables or functions in a wrong schema could be referenced in the plan. This is fixed so that, after search_path is changed, a plan is rebuilt from a new query string where table / function names are properly qualified under the latest search_path are used.

Full Changelog: v1.5...v1.5.1