Message-ID: <ff684608037760af06a332c975a3414f0c67c458.camel@j-davis.com>
Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL
 stats
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: Fri, 11 Mar 2022 19:24:12 -0800
In-Reply-To: <20220310205424.GJ10577@tamriel.snowman.net>
References: <e0315b06-7a55-6831-d1a8-f006d398da84@dunslane.net>
	 <CALj2ACWhUrjrTDffN7ctCY+6eJ=izd9itixaNYJQdd8PL1vQHA@mail.gmail.com>
	 <CAE9k0P=9SReU_613TXytZmpwL3ZRpnC5zrf96UoNCATKpK-UxQ@mail.gmail.com>
	 <CALj2ACXsu42jnjyV7zpNtGMmDCsvXr59A9x-C94uyHov2nmp6Q@mail.gmail.com>
	 <CAE9k0P=+-BKGJhx_J+eCTx6dQhkno0Z+cWRThKMf43X6W=MzRw@mail.gmail.com>
	 <CALj2ACUtqWX95uAj2VNJED0PnixEeQ=0MEzpouLi+zd_iTugRA@mail.gmail.com>
	 <CAE9k0Pn4H48D7iK=T-B2CtnCCab7DgQ4MUUCLfzFf345HmkrGQ@mail.gmail.com>
	 <CALj2ACVY37ed+BT_WeM2KQS1TUM90HO9NjNktaKCX2G6X5iXsQ@mail.gmail.com>
	 <39c13407c8b7311e9a3b24f2df814696bfa2ebff.camel@j-davis.com>
	 <CA+TgmoY4HYy89sgWTWgB9FPZ=S28=CDpDO73X-J7wRgd542hOQ@mail.gmail.com>
	 <20220310205424.GJ10577@tamriel.snowman.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/ff684608037760af06a332c975a3414f0c67c458.camel%40j-davis.com>
Precedence: bulk

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