David, * David G. Johnston ([email protected]) wrote: > On Thu, Jun 2, 2016 at 4:29 PM, Stephen Frost <[email protected]> wrote: > > > * Sameer Kumar ([email protected]) wrote: > > > On Fri, 3 Jun 2016, 12:14 a.m. Alex Ignatov, <[email protected]> > > > wrote: > > > > Can I list all WAL files in pg_xlog by using some sql query in > > Postgres? > > > > > > Try > > > > > > Select pg_ls_dir('pg_xlog'); > > > > Note that this currently requires superuser privileges. > > > > 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. > > > > Something along the lines of 'pg_xlog_file_list()', perhaps. There is a > > check in check_postgres.pl which could take advantage of this also. > > Should be a very straight-forward function to write, perhaps good as a > > starter project for someone. > > > > Isn't this the reason we created the newfangled pg_* roles in 9.6?
No, the default roles are specifically to address situations where our
GRANT system is unable to provide the privilege granularity necessary;
ie: the function needs to be executable by 'public' but should behave
differently depending on if the individual calling it has privileged
access or not.
In other words, a case like pg_cancel_query/pg_terminate_backend, where
users can cancel queries of roles they are a member of, superusers can
can cancel queries of all roles, and members of pg_signal_backend can
cancel queries for all non-superusers.
In this case, I think we'd want a whole new function, in which case it
does not need to be callable by a non-privileged individual and does not
need to distinguish between a non-privileged user, a privileged user,
and superuser.
Technically, we could have the pg_ls_dir() function check its argument
and decide to allow it if some new default role 'pg_allow_xlog_ls'
existed and the user was a member of it, but that strikes me as a whole
lot of unnecessary complexity and potential for issue, not to mention
that it certainly wouldn't be very straight-forward to document or
explain to users.
The suggested function would also be able to take additional arguments,
or maybe a second column in the result set, to extract/identify subsets
of xlogs ("xlogs waiting to be archived via archive_cmd", "xlogs being
held due to wal_keep_segments", etc).
Thanks!
Stephen
signature.asc
Description: Digital signature
