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