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 20220522202608.GA892371@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
List pgsql-hackers
On Sun, May 22, 2022 at 09:59:47AM +0900, Michael Paquier wrote:
> +    visible to superusers, roles with privileges of the
> +    <literal>pg_read_all_stats</literal> role, and roles with privileges of
> +    the user owning the session being reported on, so it should not
> +    represent a security risk. Only superusers and users with the
> +    appropriate <literal>SET</literal> privilege can change this setting.
> 
> Regarding the fact that a user can see its own information, the last
> part of the description would be right, still a bit confusing perhaps
> when it comes to one's own information?

Yeah, this crossed my mind.  I thought that "superusers, roles with
privileges of the pg_read_all_stats_role, roles with privileges of the user
owning the session being reported on, and the user owning the session being
reported on" might be too long-winded and redundant.  But I see your point
that it might be a bit confusing.  Perhaps it could be trimmed down to
something like this:

    ... 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).

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



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: PG15 beta1 sort performance regression due to Generation context change
Next
From: Andres Freund
Date:
Subject: Re: 15beta1 test failure on mips in isolation/expected/stats