Well,
I am not looking for 100% security. I know that full access if full access,
and that even if you were to encrypt the system through Postgre the
determined
person WILL always be able to get it out if they have system level access.
All I wanted to do was to prevent the basic SQL/Linux literate user from
accessing
the databases. At the moment it is very easy for them to access the data.
I trust that they wont go as far as overwriting the system with custom
compiled
version, or copying the data and so forth. It just that we would feel
much better
if we knew the data wasn't as open as it is now, with a simple pg
restart it is all
open?
Can this only be done by maybe modifying the source to make pg_hba
fields statically
compiled into the executable?
Martijn van Oosterhout wrote:
>On Wed, Feb 08, 2006 at 02:34:29PM +0200, Q Beukes wrote:
>
>
>>Is there not some other alternative to pg_hba.conf?
>>
>>I have the problem where the system administrators at our company
>>obviously have access to the whole filesystem, and our database records
>>needs to be hidden even from them.
>>
>>With pg_hba.conf that is not possible, as they just change all the conf
>>lines to "trust" auth and viola they have access to the database without
>>passwords.
>>
>>
>
>Or they just copy the whole database to another machine and access it
>that way. Or copy your backups. Or hack the application accessing the
>data (the application has the password in it, right?).
>
>If can stop them doing those things you can stop them altering
>pg_hba.conf too so your problem is solved.
>
>
>
>>Is there a more secure alternative to this? The perfect scenario being
>>to deny everyone include "root" access to a database without a password.
>>
>>
>
>Well, you could change the source to remove struct auth, but then they'd
>just compile their own version and overwrite the system one.
>
>Yes, we're looking for alternatives for pg_hba.conf, but what you want
>is to dam a river with sheets of paper.
>
>Have a nice day,
>
>
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
