Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Printing backtrace of postgres processes
Date
Msg-id 20210506194915.dfmpj3t2m2j2hgcd@alap3.anarazel.de
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2021-05-06 15:31:02 -0400, Tom Lane wrote:
> I'd probably vote for pg_read_all_data, considering that much of
> the concern about this has to do with the possibility of exposure
> of sensitive data.  I'm not quite sure what the security expectations
> are for pg_monitor.

I was wondering the same, but looking at the docs of pg_read_all_data
that doesn't seem like a great fit:

      <row>
       <entry>pg_read_all_data</entry>
       <entry>Read all data (tables, views, sequences), as if having SELECT
       rights on those objects, and USAGE rights on all schemas, even without
       having it explicitly.  This role does not have the role attribute
       <literal>BYPASSRLS</literal> set.  If RLS is being used, an administrator
       may wish to set <literal>BYPASSRLS</literal> on roles which this role is
       GRANTed to.</entry>
      </row>

It's mostly useful to be able to run pg_dump without superuser
permissions.

Contrast that to pg_monitor:

      <row>
       <entry>pg_monitor</entry>
       <entry>Read/execute various monitoring views and functions.
       This role is a member of <literal>pg_read_all_settings</literal>,
       <literal>pg_read_all_stats</literal> and
       <literal>pg_stat_scan_tables</literal>.</entry>
      </row>
...
  <para>
  The <literal>pg_monitor</literal>, <literal>pg_read_all_settings</literal>,
  <literal>pg_read_all_stats</literal> and <literal>pg_stat_scan_tables</literal>
  roles are intended to allow administrators to easily configure a role for the
  purpose of monitoring the database server. They grant a set of common privileges
  allowing the role to read various useful configuration settings, statistics and
  other system information normally restricted to superusers.
  </para>

"normally restricted to superusers" seems to fit pretty well?

I think if we follow your argument, pg_read_server_files would be a bit
better fit than pg_read_all_data? But it seems "too powerful" to me.
      <row>
       <entry>pg_read_server_files</entry>
       <entry>Allow reading files from any location the database can access on the server with COPY and
       other file-access functions.</entry>
      </row>

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: use `proc->pgxactoff` as the value of `index` in `ProcArrayRemove()`
Next
From: Robert Haas
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY