public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jeff Davis <[email protected]>
To: Stephen Frost <[email protected]>
To: Robert Haas <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Ashutosh Sharma <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Greg Stark <[email protected]>
Cc: Jeremy Schneider <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: SATYANARAYANA NARLAPURAM <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Date: Fri, 11 Mar 2022 19:24:12 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<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>
	<[email protected]>
	<CA+TgmoY4HYy89sgWTWgB9FPZ=S28=CDpDO73X-J7wRgd542hOQ@mail.gmail.com>
	<[email protected]>

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

view thread (48+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox