On Sun, Jan 17, 2016 at 6:58 PM, Stephen Frost <sfrost@snowman.net> wrote:
> I'm not against that idea, though I continue to feel that there are
> common sets of privileges which backup tools could leverage.
>
> The other issue that I'm running into, again, while considering how to
> move back to ACL-based permissions for these objects is that we can't
> grant out the actual permissions which currently exist. That means we
> either need to break backwards compatibility, which would be pretty
> ugly, in my view, or come up with new functions and then users will have
> to know which functions to use when.
>
> As I don't think we really want to break backwards compatibility or
> remove existing functionality, the only approach which is going to make
> sense is to add additional functions in some cases. In particular, we
> will need alternate versions of pg_terminate_backend and
> pg_cancel_backend. One thought I had was to make that
> 'pg_signal_backend', but that sounds like we'd allow any signal sent by
> a user with that right, which seems a bit much to me...
So, this seems like a case where a built-in role would be
well-justified. I don't really believe in built-in roles as a way of
bundling related permissions; I know you do, but I don't. I'd rather
see the individual function permissions granted individually. But
here you are talking about a variable level of access to the same
function, depending on role. And for that it seems to me that a
built-in role has a lot more to recommend it in that case than it does
in the other. If you have been granted pg_whack, you can signal any
process on the system; otherwise just your own. Those checks are
internal to pg_terminate_backend/pg_cancel_backend so GRANT is not a
substitute.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
