* Jim Nasby (Jim.Nasby@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
accidentallybreak. 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
casesto 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
happensif 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
