Re: WAL's listing in pg_xlog by some sql query

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Vik Fearing <vik(at)2ndquadrant(dot)fr>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Sameer Kumar <sameer(dot)kumar(at)ashnik(dot)com>, Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: WAL's listing in pg_xlog by some sql query
Date: 2016-06-06 12:51:40
Message-ID: 20160606125140.GI21416@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

* Vik Fearing (vik(at)2ndquadrant(dot)fr) wrote:
> On 03/06/16 04:32, Michael Paquier wrote:
> > On Fri, Jun 3, 2016 at 11:23 AM, Sameer Kumar <sameer(dot)kumar(at)ashnik(dot)com> wrote:
> >> On Fri, Jun 3, 2016 at 4:30 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >>> Given the usefulness of this specific query and that it could be used
> >>> without risk of the user being able to gain superuser access through it,
> >>> I'd like to see a new function added which does not have the superuser
> >>> check, but is not allowed to be called by public initially either.
>
> CREATE FUNCTION ls_dir(text)
> RETURNS SETOF text
> LANGUAGE sql
> SECURITY DEFINER
> AS 'select * from pg_ls_dir($1)';

This isn't a good idea as it allows access to a great deal more than
just the number of xlogs. Further, as described above, it gives that
access to everyone and not just to specific roles.

This is a great example of why we should provide an explicit function
which is documented (both in our documentation and in the documentation
of tools like check_postgres.pl) that users can use and can GRANT access
to for their monitoring systems which gives access to only the
information needed- that is, the number of xlog segments.

Thanks!

Stephen

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vik Fearing 2016-06-06 13:07:25 Re: Whither recovery.conf?
Previous Message Richard Tisch 2016-06-06 12:50:18 Whither recovery.conf?