Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nSPnq-0000Ig-VM for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Mar 2022 20:54:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nSPno-0000Ky-Ra for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Mar 2022 20:54:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nSPno-0000K7-Hn for pgsql-hackers@lists.postgresql.org; Thu, 10 Mar 2022 20:54:28 +0000 Received: from tamriel.snowman.net ([2001:470:e38f::11]) by magus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nSPnl-0005lm-Nn for pgsql-hackers@lists.postgresql.org; Thu, 10 Mar 2022 20:54:27 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id B79095F79F; Thu, 10 Mar 2022 15:54:24 -0500 (EST) Date: Thu, 10 Mar 2022 15:54:24 -0500 From: Stephen Frost To: Robert Haas Cc: Jeff Davis , Bharath Rupireddy , Ashutosh Sharma , Andrew Dunstan , Greg Stark , Jeremy Schneider , Bruce Momjian , PostgreSQL Hackers , SATYANARAYANA NARLAPURAM , marvin_liang@qq.com, actyzhang@outlook.com Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats Message-ID: <20220310205424.GJ10577@tamriel.snowman.net> References: <39c13407c8b7311e9a3b24f2df814696bfa2ebff.camel@j-davis.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ZR2l4dEWubZVuJJE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --ZR2l4dEWubZVuJJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings, * Robert Haas (robertmhaas@gmail.com) wrote: > On Thu, Mar 10, 2022 at 3:22 AM Jeff Davis wrote: > > * Can we mark this extension 'trusted'? I'm not 100% clear on the > > standards for that marker, but it seems reasonable for a database owner > > with the right privileges might want to install it. >=20 > I'm not clear on the standard either, exactly, but might not that > allow the database owner to get a peek at what's happening in other > databases? 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 the C-language functions installed have if(!superuser) ereport() calls throughout them- that's a fine answer, but it's perhaps not very helpful to mark those as trusted. In other cases, the C-language functions installed don't directly provide access to data, such as the PostGIS functions. 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. In an ideal world, we might have a pg_readwal predefined role which allows a role which was GRANT'd that role to be able to read WAL traffic, and then the pg_walinspect extension could check that the calling role has that predefined role, and other functions and extensions could also check that rather than any existing superuser checks. A cloud provider or such could then include in their setup of a new instance something like: GRANT pg_readwal TO admin_user WITH ADMIN OPTION; Presuming that there isn't anything that ends up in the WAL that's an issue for the admin_user to have access to. 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. 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. Thanks, Stephen --ZR2l4dEWubZVuJJE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJiKmWAAAoJEO1sijiDR2RV53QP/jhCbL1vbNSIyhArjlcwe7qb foifPcNQ99vexp4LZ4/4XuN5TMqi1MIzZKR0jMZfnCKF2vRXFe9/e1FCkhjWJyt5 9+V+yc7led/urb4Y7jxigIr27F9d2JHIAJolphm4zAe5zdC7byQVpIjVzbqP7BU2 vly5T6PvLKAriD/a/L1BBpdtTdRl/gVXyQjRfWeikRehGiXzGtZ8HjbNsj5oDQyO 9ZtahZN+YGr7Ryk6vkGZw4KDT9uopScz5x8dGUz3/jVTBIPltIPt6TN125vf3g8h db00X2nPTlHcex4Gg7EovpLo8fej8M8ild/rU9b5M3XGSCnur79Hxwv6Scx3tJjU +B5Q1Twy1k2JrkWL9jXoXaAHWD/JsFTZsxh63quDIeyOHqNbnz7Pelyld4ERqP/B jurHdDD2qaitBxXnlEWBphs1TxlEyxCWJZOxuXz4+xdtaAVTI4ilTcMgdW0FNmoJ osZwW8FfupwwhIy8/D1OHA5P51UgGjJNTGiPujMmKGR8TWAzN5QZlllSdNn+sRxb +V1N2CNxHq795Nrixte71rJGHXEAuMsO3V8unc5dkLGe7muRATFyho6JN4ffudZS 7tL2T9WkChjGaWtviqnIdtiKoBDTgi5Vwm3DlcshmK0Kh5mpRlpYnmW/of8q1n7r ewVvMIDwmrUUp5X+7vhn =TCWD -----END PGP SIGNATURE----- --ZR2l4dEWubZVuJJE--