Re: Printing backtrace of postgres processes

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