----- Original Message -----
From: "Bill Moran" <wmoran@xxxxxxxxxxxxxxxxxxxxxxx>
To: "woger151" <woger151@xxxxxxxxxxxxxxxx>
Cc: <pgsql-general@xxxxxxxxxxxxxx>
Sent: Wednesday, January 03, 2007 10:09 AM
Subject: Re: [GENERAL] superuser authentication?
In response to Tom Lane <tgl@xxxxxxxxxxxxx>:
"woger151" <woger151@xxxxxxxxxxxxxxxx> writes:
> What I'm not sure about is how to authenticate the postgresql superuser
> (user 'postgres' on my system). I'm considering:
> 1. Using ident (supposedly secure because of the SO_PEERCRED
> mechanism; and
> I've made a lot of effort to secure the server at the OS level)
> 2. Using password (_not_ stored on disk in e.g. pgpass)
> 3. Using reject
How are you going to do backups?
Additionally ...
While I would never caution someone _against_ more security, keep some
things in mind.
There's a user on your system that PostgreSQL runs under (probably called
"postgres"). That user owns all the files where Postgres stores the
tables
and everything else. None of that data is encrypted by Postgres (except
passwords) so any user who can su to the postgres user can bypass the
database to access the data, corrupt it, and even (if they're very clever)
modify it.
My point being, that if an attacker gets a shell on your system, they're
already very close to being able to access your PostgreSQL data.
Right, which is why "ident" seems pretty secure. The only reason I don't
just go ahead with "ident" is that one can always wonder, "what if there's a
security hole in the implementation of SO_PEERCRED?"
Personally, I'd set auth to password, then keep the password in a file in
root's home directory and set it readable by root only. If an attacker
can
read that file, he already doesn't need to.
This does mean that you'll have to carefully secure the script you use to
make backups, since they'll need to have the password in them. But you'll
need to carefully secure your backups anyway or all the other security is
rather pointless.
Right.
--
Bill Moran
Collaborative Fusion Inc.
