Re: restrict pg_stat_ssl to superuser?

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: restrict pg_stat_ssl to superuser?
Date: 2019-02-20 10:51:08
Message-ID: 3018acd9-e5d8-1e85-5ed7-47276cd77569@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-02-19 16:57, Peter Eisentraut wrote:
> On 2019-02-18 04:58, Michael Paquier wrote:
>> On Fri, Feb 15, 2019 at 02:04:59PM +0100, Peter Eisentraut wrote:
>>> We could remove default privileges from pg_stat_get_activity(). Would
>>> that be a problem?
>>
>> I don't think so, still I am wondering about the impact that this
>> could have for monitoring tools calling it directly as we document
>> it..
>
> Actually, this approach isn't going to work anyway, because function
> permissions in a view are checked as the current user, not the view owner.

So here is a patch doing it the "normal" way of nulling out all the rows
the user shouldn't see.

I haven't found any documentation of these access restrictions in the
context of pg_stat_activity. Is there something that I'm not seeing or
something that should be added?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v1-0001-Hide-other-user-s-pg_stat_ssl-rows.patch text/plain 3.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2019-02-20 10:53:37 bgwriter_lru_maxpages limits in PG 10 sample conf
Previous Message Etsuro Fujita 2019-02-20 10:50:42 Re: Another way to fix inherited UPDATE/DELETE