* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 1/21/15 6:50 PM, Stephen Frost wrote: > >>I'm still nervous about overloading this onto the roles system; I think it > >>will end up being very easy to accidentally break. But if others think > >>it'll work then I guess I'm just being paranoid. > >Break in which way..? If you're saying "it'll be easy for a user to > >misconfigure" then I might agree with you- but documentation and > >examples can help to address that. > > I'm worried about user misconfiguration. Setting up a good system of roles > (as in, distinguishing between application accounts, users, account(s) used > to deploy code changes, DBAs, etc) is already tricky because of all the > different use cases to consider. I fear that adding auditing to that matrix > is just going to make it worse.
Even with an in-core solution, users would need to work out who should
be able to configure auditing.. I agree that seeing the permission
grants to the auditing roles might be confusing for folks who have not
seen it before, but I think that'll quickly resolve itself since the
only people who would see that are those who want to use pgaudit...
> I do like Robert's idea of role:action:object triplets more, though I'm not
> sure it's enough. For example, what happens if you
I'd suggest considering what happens if you:
ALTER ROLE su_role RENAME TO new_su_role;
Or if you want to grant a non-superuser the ability to modify the
auditing rules..
Thanks,
Stephen
signature.asc
Description: Digital signature
