Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Ashutosh
Sharma <ashu.coek88@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Greg
Stark <stark@mit.edu>, Jeremy Schneider <schneider@ardentperf.com>, Bruce
Momjian <bruce@momjian.us>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>, SATYANARAYANA NARLAPURAM
<satyanarlapuram@gmail.com>, marvin_liang@qq.com, actyzhang@outlook.com
Date: 2022-03-12T03:24:12Z
Lists: pgsql-hackers
On Thu, 2022-03-10 at 15:54 -0500, Stephen Frost wrote: > The standard is basically that all of the functions it brings are > written to enforce the PG privilege system and you aren't able to use > the extension to bypass those privileges. In some cases that means > that Every extension should follow that standard, right? If it doesn't (e.g. creating dangerous functions and granting them to public), then even superuser should not install it. > the C-language functions installed have if(!superuser) ereport() > calls I'm curious why not rely on the grant system where possible? I thought we were trying to get away from explicit superuser checks. > I've not looked back on this thread, but I'd expect pg_walinspect to > need those superuser checks and with those it *could* be marked as > trusted, but that again brings into question how useful it is to mark > it > thusly. As long as any functions are safely accessible to public or a predefined role, there is some utility for the 'trusted' marker. As this patch is currently written, pg_monitor has access these functions, though I don't think that's the right privilege level at least for pg_get_raw_wal_record(). > I certainly don't think we should allow either database owners or > regular users on a system the ability to access the WAL traffic of > the > entire system. Agreed. That was not what I intended by asking if it should be marked 'trusted'. The marker only allows the non-superuser to run the CREATE EXTENSION command; it's up to the extension script to decide whether any non-superusers can do anything at all with the extension. > More forcefully- we should *not* be throwing more access > rights towards $owners in general and should be thinking about how we > can allow admins, providers, whomever, the ability to control what > rights users are given. If they're all lumped under 'owner' then > there's no way for people to provide granular access to just those > things they wish and intend to. Not sure I understand, but that sounds like a larger discussion. Regards, Jeff Davis
Commits
-
Doc build fix: remove tab from filelist.sgml.
- 8638c76cc9f4 15.0 landed
-
Add contrib/pg_walinspect.
- 2258e76f90bf 15.0 landed
-
Simplify SRFs using materialize mode in contrib/ modules
- 5b81703787bf 15.0 cited
-
Invent "trusted" extensions, and remove the pg_pltemplate catalog.
- 50fc694e4374 13.0 cited