On Tue, Jan 28, 2014 at 8:17 PM, Stephen Frost <sfr...@snowman.net> wrote:
> Greg,
> * Greg Stark (st...@mit.edu) wrote:
>> On Tue, Jan 28, 2014 at 11:56 AM, Josh Berkus <j...@agliodbs.com> wrote:
>> > 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.
>> So you can do this now by defining a security definer function that
>> extracts precisely the information you need and grant execute access
>> to precisely the users you want. There was some concern upthread about
>> defining security definer functions being tricky but I'm not sure what
>> conclusion to draw from that argument.
> Yeah, but that sucks if you want to build a generic monitoring system
> like check_postgres.pl.  Telling users to grant certain privileges may
> work out, telling them to install these pl/pgsql things you write as
> security-definer-to-superuser isn't going to be nearly as easy when
> these users are (understandably, imv) uncomfortable having a monitor
> role have superusr privs.

I couldn't agree more. Whatever we do here we need a standard
mechanism that tool developers can expect to be present and the same
on all servers. Otherwise, we make it extremely difficult to build
tools like pgAdmin, check_postgres.pl and so on.

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to