From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view |
Date: | 2024-03-13 17:08:09 |
Message-ID: | ZfHdeer_0QxksV5p@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Mar 12, 2024 at 01:22:33PM +0100, Laurenz Albe wrote:
> On Tue, 2024-03-12 at 12:40 +0200, Maxim Boguk wrote:
> > May I suggest a change to always allow superuser run
> > REFRESH MATERIALIZED VIEW (may be via set role or similar mechanics)?
>
> If the query ran with superuser permissions, that would be
> a security problem:
>
> CREATE TABLE log (t text);
>
> CREATE FUNCTION f() RETURNS integer LANGUAGE sql
> AS 'INSERT INTO log VALUES (''x''); SELECT 42';
>
> CREATE MATERIALIZED VIEW v AS SELECT f();
>
> Now imagine you create a malicious trigger on "log" and
> get a superuser to refresh the materialized view.
>
>
> I don't see why it should be a problem if a superuser gets
> "permission denied" in such a case. They can also get it if
> they call a SECURITY DEFINER function owned by a non-superuser.
Can we improve the error that superusers get so they realize how to fix
it?
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-03-13 18:32:55 | Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view |
Previous Message | Noah Misch | 2024-03-13 16:55:23 | Re: FSM Corruption (was: Could not read block at end of the relation) |