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: http://www.postgresql.org/mailpref/pgsql-hackers
