| 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: | Whole Thread | Raw Message | 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 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergei Kornilov | 2019-02-20 10:53:37 | bgwriter_lru_maxpages limits in PG 10 sample conf |
| Previous Message | Oleksii Kliukin | 2019-02-20 10:50:42 | Re: Prepared transaction releasing locks before deregistering its GID |