Re: proposal: hide application_name from other users - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: proposal: hide application_name from other users
Date
Msg-id CA+U5nMJhFziTe5smPNy-EtJ16P2HummK1iqcvq_vqCwrWubR9w@mail.gmail.com
Whole thread Raw
In response to Re: proposal: hide application_name from other users  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 28 January 2014 20:14, Josh Berkus <josh@agliodbs.com> wrote:
> On 01/28/2014 12:10 PM, Tom Lane wrote:
>> Josh Berkus <josh@agliodbs.com> writes:
>>> For example, I would really like to GRANT an unpriv user access to the
>>> WAL columns in pg_stat_replication so that I can monitor replication
>>> delay without granting superuser permissions.
>>
>> Just out of curiosity, why is that superuser-only at all?  AFAICS the
>> hidden columns are just some LSNs ... what is the security argument
>> for hiding them in the first place?
>
> Beats me, I can't find any discussion on it at all.

No specific reason that I can recall but replication is heavily
protected by layers of security.

pg_stat_replication is a join with pg_stat_activity, so some of the
info is open, some closed. It seems possible to relax that.


Presumably the current patch is returned with feedback? Or can we fix
these problems by inventing a new user aspect called MONITOR (similar
to REPLICATION)? We can grant application_name and replication details
to that.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Next
From: Tom Lane
Date:
Subject: Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()