Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?

Isaac Morland <isaac.morland@gmail.com>

From: Isaac Morland <isaac.morland@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Stephen Frost <sfrost@snowman.net>, "Bossart, Nathan" <bossartn@amazon.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-14T16:44:37Z
Lists: pgsql-hackers
On Thu, 14 Oct 2021 at 09:11, Robert Haas <robertmhaas@gmail.com> wrote:

>
> According to https://www.postgresql.org/docs/current/sql-createview.html
> it always works like that: "Access to tables referenced in the view is
> determined by permissions of the view owner. In some cases, this can
> be used to provide secure but restricted access to the underlying
> tables."
>
> Hmm, unless that rule is only being applied for *tables* and not for
> *functions*? I guess that could be true, but if so, it sure seems
> inconsistent.
>

Yes, I think this has come up before. It seems obvious to me that a view
should execute entirely in the context of its owner. I should be able to
use functions to define view columns without requiring that access to those
functions be handed out to users of the view.

I feel this might relate to the discussion of triggers, which I claim
should execute in the context of the table owner (or maybe the trigger
owner, if that were a separate concept). There are lots of triggers one
might want to write that cannot be written because they execute in the
context of the user of the table; my recollection is that it is harder to
find examples of non-malware triggers that depend on executing in the
context of the user of the table.

Commits

  1. Grant memory views to pg_read_all_stats.