Re: Printing backtrace of postgres processes
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, vignesh C <vignesh21@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Craig Ringer <craig.ringer@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-06T19:49:15Z
Lists: 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
Commits
-
Perform apply of large transactions by parallel workers.
- 216a784829c2 16.0 cited
-
Enhance pg_log_backend_memory_contexts() for auxiliary processes.
- 790fbda90209 15.0 cited
-
Allow GRANT on pg_log_backend_memory_contexts().
- f0b051e322d5 15.0 cited
-
Move Perl test modules to a better namespace
- b3b4d8e68ae8 15.0 cited
-
Unify PostgresNode's new() and get_new_node() methods
- 201a76183e20 15.0 cited
-
Add backtrace support for error reporting
- 71a8a4f6e365 13.0 cited