On Fri, Nov 20, 2015 at 12:29 PM, Stephen Frost <sfr...@snowman.net> wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Thu, Nov 19, 2015 at 7:10 AM, Stephen Frost wrote:
>> > * Michael Paquier (michael.paqu...@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 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.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to