On Sun, Jan 17, 2016 at 6:58 PM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
