Re: should we allow users with a predefined role to access pg_backend_memory_contexts view and pg_log_backend_memory_contexts function?
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Stephen Frost <sfrost@snowman.net>, Isaac Morland
<isaac.morland@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, "Bossart, Nathan"
<bossartn@amazon.com>, Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>
Date: 2021-10-14T18:14:47Z
Lists: pgsql-hackers
On Thu, 2021-10-14 at 13:43 -0400, Stephen Frost wrote: > I'm not sure that it's really inconsistent- if you want the function > to > run as someone else, define it as SECURITY DEFINER and it will. There are two issues: 1. Does having permissions to read a view give the reader the ability to execute the function as a part of reading the view? Here it seems like we should allow the user to execute the function that's a part of the view. If it's doing something that performs another permission check, then it could fail, but at least they'd be able to execute it. That seems consistent with the ability to read tables as a part of reading the view. 2. If the function is executed, is it SECURITY INVOKER or SECURITY DEFINER? I think here the answer is SECURITY INVOKER. SECURITY DEFINER doesn't even really make sense, because the definer might not be the owner of the view. Maybe we need a concept where the function is executed as neither the invoker or the definer, but as the owner of the view (or something else), which sounds appealing, but sounds more like a new feature. Regards, Jeff Davis
Commits
-
Grant memory views to pg_read_all_stats.
- 77ea4f94393e 15.0 landed