* Jim Nasby (jim.na...@bluetreble.com) wrote: > On 2/17/15 12:07 PM, Stephen Frost wrote: > >I agree that it's not the auditing job to stop or control access to > >data, but it's not so simple to audit the superuser completely. The > >issue is that even if you have a hard-coded bit in the binary which says > >"audit everything", a superuser can change the running code to twiddle > >that bit off, redirect the output of whatever auditing is happening, > >gain OS-level (eg: shell) access to the system and then make changes to > >the files under PG directly, etc. Setting a bit in a binary and then > >not allowing that binary to be unchanged does not actually solve the > >issue. > > If we've allowed a superuser *in the database* that kind of power at > the OS level then we have a problem. There needs to be *something* > that a database SU can't do at the OS level, otherwise we'll never > be able to audit database SU activity.
This isn't a question. The database superuser has essentially OS-level
privileges as the user which PG runs as.
I'm all for coming up with a less powerful superuser and the work I've
been involved in around adding more role attributes is along the lines
to get us there, but I don't think we're ever going to really reduce the
power that the PG superuser has, for a variety of reasons.
Improving the documentation of what a superuser can do and how granting
such access is the same as giving OS shell-level access to the system as
the user that PG runs as would certainly be good.
Thanks,
Stephen
signature.asc
Description: Digital signature
