* Robert Haas (robertmhaas@gmail.com) wrote:
> On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Michael Paquier (michael.paquier@gmail.com) wrote:
> >> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
> >> > * Michael Paquier (michael.paquier@gmail.com) wrote:
> >> >> It seems weird to not have a dedicated role for pg_switch_xlog.
> >> >
> >> > I didn't add a pg_switch_xlog default role in this patch series, but
> >> > would be happy to do so if that's the consensus. It's quite easy to do.
> >>
> >> Agreed. I am not actually getting why that's part of the backup
> >> actually. That would be more related to archiving, both being
> >> unrelated concepts. But at this point I guess that's mainly a
> >> philosophical split.
> >
> > As David notes, they're actually quite related. Note that in our
> > documentation pg_switch_xlog() is listed in the "Backup Control
> > Functions" table.
> >
> > I can think of a use-case for a user who can call pg_switch_xlog, but
> > not pg_start_backup()/pg_stop_backup(), but I have to admit that it
> > seems rather limited and I'm on the fence about it being a worthwhile
> > distinction.
>
> Sounds too narrow to me. Are we going to have a separate predefined
> role for every security-restricted function to which someone might
> want to grant access? That seems over the top to me.
I certainly don't want to go down to that level and was, as seen above,
unsure about having pg_switch_xlog() as a differentiated privilege.
Michael, do you still see that as a useful independent capability?
> I don't think we should make it our goal to completely eliminate the
> use of SECURITY DEFINER functions for privilege delegation. Of
> course, being able to grant privileges directly is nicer, because then
> the client code doesn't have to know about it. But I think it's OK,
> even good, if the predefined roles cater to the common cases, and the
> less common cases aren't handled quite as elegantly.
Agreed.
Thanks!
Stephen
