On Tue, Jan 28, 2014 at 8:17 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Greg,
>
> * Greg Stark (stark@mit.edu) wrote:
>> On Tue, Jan 28, 2014 at 11:56 AM, Josh Berkus <josh@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