From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Jensen Somers <jensen(at)aimproductions(dot)be> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Install PostgreSQL as part of a desktop application, but how to coop with existing installations? |
Date: | 2011-01-18 01:22:09 |
Message-ID: | 4D34EB41.9020604@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 01/17/2011 11:31 PM, Jensen Somers wrote:
> But, from your initial reply I understood that a user can simply browse
> to my database installation folder (e.g.: C:/ProgramData/MyApp/data),
> read out and/or modify a configuration file and he can access the entire
> database and modify the data. And that's what I want to prevent.
Correct. If the user has local administrator rights on their computer
(as is the case with basically all non-corporate systems) they can just
find and modify pg_hba.conf to set "trust" authentication then connect
with PgAdmin III or psql and do what they like.
PostgreSQL doesn't attempt to provide half-measure security against a
local user with system administrative rights. That's mostly because,
unlike the other databases you're talking about, it's not really
designed for application embedded use.
You might want to check out Firebird, which is designed for embedded
use. I don't know if it has encrypted data file storage options and
other weak-security-against-priveleged-local-user stuff, but it's going
to be a more viable option than Pg will.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-01-18 04:36:09 | Re: help understanding collation order |
Previous Message | Alex Hunsaker | 2011-01-17 23:47:43 | Re: plpythonu memory leak |