Re: docs: mention "pg_read_all_stats" in "track_activities" description - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: docs: mention "pg_read_all_stats" in "track_activities" description
Date
Msg-id 20220523164142.GB938919@nathanxps13
Whole thread Raw
In response to Re: docs: mention "pg_read_all_stats" in "track_activities" description  (Michael Paquier <michael@paquier.xyz>)
Responses Re: docs: mention "pg_read_all_stats" in "track_activities" description  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Mon, May 23, 2022 at 08:53:24AM +0900, Michael Paquier wrote:
> On Sun, May 22, 2022 at 01:26:08PM -0700, Nathan Bossart wrote:
>>     ... superusers, roles with privileges of the pg_read_all_stats role,
>>     and roles with privileges of the user owning the session being reported
>>     on (including the session owner).
> 
> Yeah, that sounds better to me.  monitoring.sgml has a different way
> of wording what looks like the same thing for pg_stat_xact_*_tables:
> "Ordinary users can only see all the information about their own
> sessions (sessions belonging to a role that they are a member of)".
> 
> So you could say instead something like: this information is only
> visible to superusers, roles with privileges of the pg_read_all_stats
> role, and the user owning the sessionS being reported on (including
> sessions belonging to a role that they are a member of).

I think we need to be careful about saying "member of" when we really mean
"roles with privileges of."  Unless I am mistaken, role membership alone is
not sufficient for viewing this information.  You also need to inherit the
role's privileges via INHERIT.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Add --{no-,}bypassrls flags to createuser
Next
From: Nathan Bossart
Date:
Subject: Re: allow building trusted languages without the untrusted versions