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
-
Grant memory views to pg_read_all_stats.
- 77ea4f94393e 15.0 landed