Обсуждение: Install PostgreSQL as part of a desktop application, but how to coop with existing installations?

Hi,

I am looking into using PostgreSQL as a database service in a desktop
application since it's one of the support local database systems by
DataObjects.net and has more features and higher limitations than SQL
server express. I prefer a database versus a traditional binary data
file, but I ran into some limitations when using either SQLite or SQL CE
3.5. (Support, file lize limitations, no batch processing support, ...)

I know that some applications (Poker Tracker 3 is the first one that
comes to my mind) install PostgreSQL during their installation process
too and setup the initial database. I sort of figured out how to do
this, but I don't know how to deal with an already existing installation
during setup. What if the user doesn't now the master server password.
As far as I understand this means I cannot continue the installation
process and create my databases.

Is there somewhere a guide to include and configure PostgreSQL as part
of a desktop application? More precisely installation and configuration
steps that clarify my question?

- Jensen

On 01/14/2011 06:26 AM, Jensen Somers wrote:

> I know that some applications (Poker Tracker 3 is the first one that
> comes to my mind)

It's not a good example, either, as demonstrated by the number of
questions that pop up about it on this list, and the incredibly ancient
versions of Pg that they bundle.

> install PostgreSQL during their installation process
> too and setup the initial database. I sort of figured out how to do
> this, but I don't know how to deal with an already existing installation
> during setup.

I take it you're talking about doing a silent install using the
postgresql exe installer, by invoking it as part of your own app's
installer?

Personally, that's not how I'd do it if I were bundling Pg in my
(Windows) app, because as you mentioned it may interfere with any
existing or future Pg install the user wants to do manually. It'll also
show up separately in add/remove programs, which I think is undesirable
when it's just being installed as a component of your app.

If my app required Pg, I'd probably bundle the Pg installation tree in
my installer and copy it into my program's install directory. I'd then
create a non-login user account named after my application (NOT
"postgres"), set up the service (again named for my application), and
invoke initdb to create the database under that service account. I'd
generate a postgresql.conf with a semi-random fairly high port number
that wasn't already in use on the target machine, to avoid conflicting
with the commonly used postgresql port. All this can be done using the
scripting languages provided by most installers, or via simple Windows
command line tools like "net.exe" and friends. If your installer is
particularly limited, you can always write and bundle a simple helper
program for it to invoke to do the work. My uninstaller would prompt the
user to ask if they wanted to remove data as well as the program; if
they said yes I'd remove the datadir and the user account I'd created
during installation.

This way, your instance of PostgreSQL is private to your app and doesn't
conflict with anything the user might want to do. You can upgrade it
when you upgrade your app, provide backup facilities for it in your app,
etc etc without the user having to care what's behind the scenes.


If that wasn't viable, the only other option  I'd consider would be
providing a postgresql installer and asking the user to install it if
they didn't already have it installed. I'd then prompt for the database
host, port, username, password and database name to connect to, and
would just use what was provided to me. This is almost certainly how it
should be done on UNIX/Linux platforms.

--
Craig Ringer

Hi,

On 14/01/2011 7:35, Craig Ringer wrote:
> On 01/14/2011 06:26 AM, Jensen Somers wrote:
>
>> I know that some applications (Poker Tracker 3 is the first one that
>> comes to my mind)
>
> It's not a good example, either, as demonstrated by the number of
> questions that pop up about it on this list, and the incredibly
> ancient versions of Pg that they bundle.
>
>> install PostgreSQL during their installation process
>> too and setup the initial database. I sort of figured out how to do
>> this, but I don't know how to deal with an already existing installation
>> during setup.
>
> I take it you're talking about doing a silent install using the
> postgresql exe installer, by invoking it as part of your own app's
> installer?
>
> Personally, that's not how I'd do it if I were bundling Pg in my
> (Windows) app, because as you mentioned it may interfere with any
> existing or future Pg install the user wants to do manually. It'll
> also show up separately in add/remove programs, which I think is
> undesirable when it's just being installed as a component of your app.
>
> If my app required Pg, I'd probably bundle the Pg installation tree in
> my installer and copy it into my program's install directory. I'd then
> create a non-login user account named after my application (NOT
> "postgres"), set up the service (again named for my application), and
> invoke initdb to create the database under that service account. I'd
> generate a postgresql.conf with a semi-random fairly high port number
> that wasn't already in use on the target machine, to avoid conflicting
> with the commonly used postgresql port. All this can be done using the
> scripting languages provided by most installers, or via simple Windows
> command line tools like "net.exe" and friends. If your installer is
> particularly limited, you can always write and bundle a simple helper
> program for it to invoke to do the work. My uninstaller would prompt
> the user to ask if they wanted to remove data as well as the program;
> if they said yes I'd remove the datadir and the user account I'd
> created during installation.
>
> This way, your instance of PostgreSQL is private to your app and
> doesn't conflict with anything the user might want to do. You can
> upgrade it when you upgrade your app, provide backup facilities for it
> in your app, etc etc without the user having to care what's behind the
> scenes.
>
>
> If that wasn't viable, the only other option  I'd consider would be
> providing a postgresql installer and asking the user to install it if
> they didn't already have it installed. I'd then prompt for the
> database host, port, username, password and database name to connect
> to, and would just use what was provided to me. This is almost
> certainly how it should be done on UNIX/Linux platforms.
>
> --
> Craig Ringer

Bundling it as part of my application is even better. I didn't knew if
that would be possible, but it would solve some of the issues. Mainly
data protection. The data that needs to be stored should not be altered
by users. If they have access to the database via a root password, which
would be the case when using the installer or an existing server they
can manipulate the data. Implementing your suggested solution would
prevent all that, which makes it a perfect solution.

Thanks, I know what I'll be doing today!

- Jensen

On 01/14/2011 03:45 PM, Jensen Somers wrote:
> Bundling it as part of my application is even better. I didn't knew if
> that would be possible, but it would solve some of the issues. Mainly
> data protection. The data that needs to be stored should not be altered
> by users. If they have access to the database via a root password, which
> would be the case when using the installer or an existing server they
> can manipulate the data. Implementing your suggested solution would
> prevent all that, which makes it a perfect solution.

Not so much.

If the user has the access rights to install your app, they also have
access rights to modify it or components of it later. Bundling Pg with
the app gains nothing in security terms, as the user can just modify the
Pg service or user account, alter pg_hba.conf, directly copy the Pg data
files, etc etc etc.

If the user requires intervention from a system/network administrator to
install the app (via a priv elevation prompt, "run as administrator"
etc) then the admin is not forced to disclose any Pg admin access
details to the final user, who also lacks the rights to override them.
In this case bundling Pg with the app gains nothing in security terms,
as a regular Pg install is already secured against the local
unpriveleged user.

Bundling Pg will gain you convenience, easier app updates/maintenance
(if done right), and a lower impact on the user, but it won't help you
isolate Pg data from the user.

A few other considerations, since you're interested in the security side
of things:

Even if the user lacks admin rights on the machine, if they have
physical access to the machine they can get admin rights. A BIOS
password and locked boot order help a little, but won't stop someone
who's happy to open the case. Full HDD encryption and "trusted boot"
_might_ stop them. Even if you store the database its self on a
different host, the user will be able to break their own machine enough
to extract the authentication credentials and access the database directly.

If preventing the user from accessing/manipulating data directly is a
really strict requirement you'll need the database to run on a separate,
physically secure machine, and your app will need to run as a database
user with only the access rights the user should have. If the user
shouldn't be able to do it directly, the app shouldn't be able to do it
via the database. If you can't implement your requirements using
database-level security you'll need a "middleware" tool running on a
physically secure host, and you'll need to do all database access via
that app. It can enforce your business rules about who is allowed to
see/modify what, when.

--
Craig Ringer

> Bundling it as part of my application is even better. I didn't knew if
> that would be possible, but it would solve some of the issues.

Oh, I meant to mention: Whether bundling directly in your installer or
invoking the exe installer silently, you need to consider the major
version incompatibility problem. The user might install version 1.0 of
your app (which bundles Pg 8.4), uninstall it, and then install version
2.0 of your app (which bundles Pg 9.0). The user expects their data to
still be there ... but your 9.0 instance can't read the data from 8.4,
so it fails to start. Alternately, if you initdb'd in a new location,
the user sees a new blank database without their data in it and has no
way to access the old data.

Possible workarounds are:
- force a pg_dump backup to be run during uninstallation; or
- make the installer check for old data directories and use pg_upgrade

Both require testing and careful thought. It's a pain, and one of the
reasons Pg isn't great for bundling/embedding in apps.

--
Craig Ringer

Hi,

On 15/01/2011 14:21, Craig Ringer wrote:
> On 01/14/2011 03:45 PM, Jensen Somers wrote:
>> Bundling it as part of my application is even better. I didn't knew if
>> that would be possible, but it would solve some of the issues. Mainly
>> data protection. The data that needs to be stored should not be altered
>> by users. If they have access to the database via a root password, which
>> would be the case when using the installer or an existing server they
>> can manipulate the data. Implementing your suggested solution would
>> prevent all that, which makes it a perfect solution.
>
> Not so much.
>
> If the user has the access rights to install your app, they also have
> access rights to modify it or components of it later. Bundling Pg with
> the app gains nothing in security terms, as the user can just modify
> the Pg service or user account, alter pg_hba.conf, directly copy the
> Pg data files, etc etc etc.
>
> If the user requires intervention from a system/network administrator
> to install the app (via a priv elevation prompt, "run as
> administrator" etc) then the admin is not forced to disclose any Pg
> admin access details to the final user, who also lacks the rights to
> override them. In this case bundling Pg with the app gains nothing in
> security terms, as a regular Pg install is already secured against the
> local unpriveleged user.
>
> Bundling Pg will gain you convenience, easier app updates/maintenance
> (if done right), and a lower impact on the user, but it won't help you
> isolate Pg data from the user.
>
> A few other considerations, since you're interested in the security
> side of things:
>
> Even if the user lacks admin rights on the machine, if they have
> physical access to the machine they can get admin rights. A BIOS
> password and locked boot order help a little, but won't stop someone
> who's happy to open the case. Full HDD encryption and "trusted boot"
> _might_ stop them. Even if you store the database its self on a
> different host, the user will be able to break their own machine
> enough to extract the authentication credentials and access the
> database directly.
>
> If preventing the user from accessing/manipulating data directly is a
> really strict requirement you'll need the database to run on a
> separate, physically secure machine, and your app will need to run as
> a database user with only the access rights the user should have. If
> the user shouldn't be able to do it directly, the app shouldn't be
> able to do it via the database. If you can't implement your
> requirements using database-level security you'll need a "middleware"
> tool running on a physically secure host, and you'll need to do all
> database access via that app. It can enforce your business rules about
> who is allowed to see/modify what, when.
>
> --
> Craig Ringer

That's a real bummer.

I am migrating from a binary data format. But it's hard to maintain and
add new features. Most of the operations I need to perform on the data
is list, sort and analyze, which is why I'm interested into using a
database as a back-end solution.
Once a recording session is completed the data should be locked and not
modified anymore. And everything should be local on the user's PC, I
can't use an external database server. My first idea was to use SQL
Compact Edition. It can easily create a file which I can password
protect so a user cannot open the file and modify the data. But SQL CE
has some limitations which is why I am very interested into using
PostgreSQL as a database service.

I have no problem with a user knowing I use PostgreSQL, but if there's
no way I can block him out of the database and prevent him from
manipulating the data in any way PostgreSQL is, unfortunately,  no
longer an option.

- Jensen

On 01/17/2011 06:46 PM, Jensen Somers wrote:

> Once a recording session is completed the data should be locked and not
> modified anymore. And everything should be local on the user's PC, I
> can't use an external database server.

Those two requirements are mutually exclusive, unless you're willing to
qualify and limit one or both of them with something like "the user must
not have local admin rights". As stated, you've set yourself
requirements that are impossible to satisfy with ANY database system.

If the user has local admin, then everything is modifiable with varying
degrees of effort. You can potentially both your requirements if the
local user can be guanteed NOT have admin rights, by configuring privs
in the database to permit INSERT but not UPDATE/DELETE on the tables of
interest, or by using SECURITY DEFINER functions to perform limited
priveleged tasks (like "archive this batch into the
read-only-to-normal-users history tables).

No matter what data storage system you use, if your data or the
credentials that grant unlimited read/write access to that data on a
remote server are on the local machine and the user has local admin
rights, your data isn't really read-only. It might be "trickier to
modify", but that's about it. That might be good enough, depending on
how strong your requirement for read-only archival is. If it's a
legal/compliance requirement, you're stuffed, you need non-admin users
or a remote server + limited database access credentials. If it's just
to make playing with the history by accident unlikely and make casual
tampering hard, then maybe it'll be OK to keep the data local even with
a local admin user. They'll at least have to jump through a few hoops to
bypass the app and start modifying the data directly.

This applies to Pg, MS SQL Express, MySQL, SQLite, etc. If the user has
local admin rights, you have no security against them.

> My first idea was to use SQL
> Compact Edition. It can easily create a file which I can password
> protect so a user cannot open the file and modify the data.

... except by brute-force cracking the password, examining your program
binary to extract and read the password, capturing the password using a
debugger as your program passes it to the MS SQL Compact Edition library
calls, using their local admin rights to load a malicious DLL that
intercepts the calls and logs the password, ... etc etc etc.

How secure does it have to be? Against whom? What must it prevent, and
what things may it let past? Define your requirements in detail, THEN
start thinking about how to satisfy them.

> I have no problem with a user knowing I use PostgreSQL, but if there's
> no way I can block him out of the database and prevent him from
> manipulating the data in any way PostgreSQL is, unfortunately, no longer
> an option.

There is no way you can lock the user out of ****ANY**** database, data
file, etc if they have local administrator rights on the computer, the
data is on that computer, and the credentials used to access that data
(embedded in your program or otherwise) are also on the computer. None.
Zero. Nil. All you can do is make it harder for them to varying degrees.

Even if they don't have local admin, if they have physical access to the
computer they can get local admin if they particularly want it. Boot an
ubuntu CD / USB key, reset the NT password for the local admin, and
you're done. Easy. Or do the same thing over PXE (network boot) by
plugging in a laptop and spoofing the DHCP server. Numerous other tools
can be used instead of a linux boot CD, and there are may other ways to
backdoor a system than changing the admin password. The only way you can
stop them is by denying physical access and denying local admin rights.

So: How secure does it have to be?

(You **might** be able to keep it secure against a non-admin user with
physical access if you had a system with a "trusted boot" chain using
the TPM, etc. I doubt you'll be able to require that, though!)

--
Craig Ringer

On Mon, Jan 17, 2011 at 11:46:11AM +0100, Jensen Somers wrote:
> I am migrating from a binary data format. But it's hard to maintain and
> add new features. Most of the operations I need to perform on the data
> is list, sort and analyze, which is why I'm interested into using a
> database as a back-end solution.

> Once a recording session is completed the data should be locked and not
> modified anymore.

> I have no problem with a user knowing I use PostgreSQL, but if there's
> no way I can block him out of the database and prevent him from
> manipulating the data in any way PostgreSQL is, unfortunately,  no
> longer an option.

If the user has control of the data, then the user can modify it.  If
your current binary data file is on the user's machine, there is
effectively no way for you to prevent the user from modifying the data
in some way.  The same is true here.

What you can do, of course, is encrypt the data on the way in, and put
checksums on the data (both on each row and on a series) to detect
that data has been altered.  Of course, the entire series could be
replaced.  Since you say no interaction with an outside system is
possible, the encryption keys are going to have to be available in the
application too, so I wouldn't put too much faith in that.

You need to figure out how valuable the data is, how much it would be
worth to the user to be able to alter the data, and then make your
data more secure than that.  Hard guarantees about the safety of data
that is in the hands of a potential attacker are simply not possible.
(If you don't believe me, consider the failures of the various
security arrangements on smart cards, SIMs for mobile phones, and so
on.  If the user has everything it needs available locally, then it is
always possible for the user to get control.  It's just a question of
whether it's worth doing.

There are alternatives; for instance, you could have a "lazy"
replication system to some other system -- one that perhaps only
captures changes to metadata rather than the actual data, so that user
data isn't actually shipped to you, or something.  It is also possible
to subvert this sort of system, but it's more work & therefore raises
the cost of such a system.  (In this kind of system, to be secure,
each piece of metadata needs to include a reference to the previous
one in the chain.  It's hard to yank one piece out without replacing
everything that comes after it, so such an attack would be easier to
detect.  Not an impossible attack, just harder.)

A

--
Andrew Sullivan
ajs@crankycanuck.ca

Hi,

On 17/01/2011 14:49, Craig Ringer wrote:
> On 01/17/2011 06:46 PM, Jensen Somers wrote:
>
>> Once a recording session is completed the data should be locked and not
>> modified anymore. And everything should be local on the user's PC, I
>> can't use an external database server.
>
> Those two requirements are mutually exclusive, unless you're willing
> to qualify and limit one or both of them with something like "the user
> must not have local admin rights". As stated, you've set yourself
> requirements that are impossible to satisfy with ANY database system.
>
> If the user has local admin, then everything is modifiable with
> varying degrees of effort. You can potentially both your requirements
> if the local user can be guanteed NOT have admin rights, by
> configuring privs in the database to permit INSERT but not
> UPDATE/DELETE on the tables of interest, or by using SECURITY DEFINER
> functions to perform limited priveleged tasks (like "archive this
> batch into the read-only-to-normal-users history tables).
>
> No matter what data storage system you use, if your data or the
> credentials that grant unlimited read/write access to that data on a
> remote server are on the local machine and the user has local admin
> rights, your data isn't really read-only. It might be "trickier to
> modify", but that's about it. That might be good enough, depending on
> how strong your requirement for read-only archival is. If it's a
> legal/compliance requirement, you're stuffed, you need non-admin users
> or a remote server + limited database access credentials. If it's just
> to make playing with the history by accident unlikely and make casual
> tampering hard, then maybe it'll be OK to keep the data local even
> with a local admin user. They'll at least have to jump through a few
> hoops to bypass the app and start modifying the data directly.
>
> This applies to Pg, MS SQL Express, MySQL, SQLite, etc. If the user
> has local admin rights, you have no security against them.
>
>> My first idea was to use SQL
>> Compact Edition. It can easily create a file which I can password
>> protect so a user cannot open the file and modify the data.
>
> ... except by brute-force cracking the password, examining your
> program binary to extract and read the password, capturing the
> password using a debugger as your program passes it to the MS SQL
> Compact Edition library calls, using their local admin rights to load
> a malicious DLL that intercepts the calls and logs the password, ...
> etc etc etc.
That's something I know I can't do anything against. But that's the same
problem I face now with my binary data format and so far I have not seen
any user able to modify it. I know from the user forums that a lot of
people tried, but they failed. But I can achieve the same thing by
password protecting the SQL CE or SQLite database file. And that's good
enough for me, I know I cannot get a 100% secure solution, but the one I
can get is good enough for me. Since my application is used by a very
small number of users world wide ( < 10.000) I don't really need to
worry about it being cracked in the same way Adobe or Microsoft needs to
worry.
>
> How secure does it have to be? Against whom? What must it prevent, and
> what things may it let past? Define your requirements in detail, THEN
> start thinking about how to satisfy them.
>
>> I have no problem with a user knowing I use PostgreSQL, but if there's
>> no way I can block him out of the database and prevent him from
>> manipulating the data in any way PostgreSQL is, unfortunately, no longer
>> an option.
>
> There is no way you can lock the user out of ****ANY**** database,
> data file, etc if they have local administrator rights on the
> computer, the data is on that computer, and the credentials used to
> access that data (embedded in your program or otherwise) are also on
> the computer. None. Zero. Nil. All you can do is make it harder for
> them to varying degrees.
I can hide the credentials in my application, that's what I currently
also need to do in order to access the binary data file.

The data that is logged can be uploaded, only if a user desires, to a
web service which process the data and compares it against other user.
What we saw from previous application versions which used an XML based
file format is that a lot of users manipulated their data to get better
results. That was "fixed" by introducing our binary format, but that has
proven to be hard to maintain and work with in general which is my I am
currently looking into database solutions. And I want to provide some
protection, I don't want the data to be wide open to everyone.
>
> Even if they don't have local admin, if they have physical access to
> the computer they can get local admin if they particularly want it.
> Boot an ubuntu CD / USB key, reset the NT password for the local
> admin, and you're done. Easy. Or do the same thing over PXE (network
> boot) by plugging in a laptop and spoofing the DHCP server. Numerous
> other tools can be used instead of a linux boot CD, and there are may
> other ways to backdoor a system than changing the admin password. The
> only way you can stop them is by denying physical access and denying
> local admin rights.
>
> So: How secure does it have to be?
The password protection I can get using SQLite or SQL CE is more than
enough. If I can do the same thing with PostgreSQL it's OK. Creating a
database user for my application is what I planned to do. I am also in
no way interested in the user's computer user or admin rights, I am just
talking about a database user.

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.
> (You **might** be able to keep it secure against a non-admin user with
> physical access if you had a system with a "trusted boot" chain using
> the TPM, etc. I doubt you'll be able to require that, though!)
>
> --
> Craig Ringer

- Jensen

On Mon, Jan 17, 2011 at 04:31:45PM +0100, 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.

Dunno about CE, but this is also trivial using SQLite.

But also, given your needs, I wonder pretty seriously whether Postgres
is the right thing for your application.  It sounds like this is
always single-user with no contention.  Postgres is a bad fit for
that.  Use SQLite or one of the other things that target embedded use.

A

--
Andrew Sullivan
ajs@crankycanuck.ca

On 17/01/2011 16:46, Andrew Sullivan wrote:
> On Mon, Jan 17, 2011 at 04:31:45PM +0100, 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.
> Dunno about CE, but this is also trivial using SQLite.
>
> But also, given your needs, I wonder pretty seriously whether Postgres
> is the right thing for your application.  It sounds like this is
> always single-user with no contention.  Postgres is a bad fit for
> that.  Use SQLite or one of the other things that target embedded use.
>
> A

The problem is that the library I want to use does not support SQLite as
a database provider and SQL CE is limited to a database file of 4GB and
lacks several interesting SQL features, hence why I was interested in
using PostgreSQL.

- Jensen

On Monday 17 January 2011 8:11:20 am Jensen Somers wrote:
> On 17/01/2011 16:46, Andrew Sullivan wrote:
> > On Mon, Jan 17, 2011 at 04:31:45PM +0100, 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.
> >
> > Dunno about CE, but this is also trivial using SQLite.
> >
> > But also, given your needs, I wonder pretty seriously whether Postgres
> > is the right thing for your application.  It sounds like this is
> > always single-user with no contention.  Postgres is a bad fit for
> > that.  Use SQLite or one of the other things that target embedded use.
> >
> > A
>
> The problem is that the library I want to use does not support SQLite as
> a database provider and SQL CE is limited to a database file of 4GB and
> lacks several interesting SQL features, hence why I was interested in
> using PostgreSQL.
>
> - Jensen

Out of curiosity what library is that?

--
Adrian Klaver
adrian.klaver@gmail.com

On 17/01/2011 17:26, Adrian Klaver wrote:
> On Monday 17 January 2011 8:11:20 am Jensen Somers wrote:
>> On 17/01/2011 16:46, Andrew Sullivan wrote:
>>> On Mon, Jan 17, 2011 at 04:31:45PM +0100, 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.
>>> Dunno about CE, but this is also trivial using SQLite.
>>>
>>> But also, given your needs, I wonder pretty seriously whether Postgres
>>> is the right thing for your application.  It sounds like this is
>>> always single-user with no contention.  Postgres is a bad fit for
>>> that.  Use SQLite or one of the other things that target embedded use.
>>>
>>> A
>> The problem is that the library I want to use does not support SQLite as
>> a database provider and SQL CE is limited to a database file of 4GB and
>> lacks several interesting SQL features, hence why I was interested in
>> using PostgreSQL.
>>
>> - Jensen
> Out of curiosity what library is that?
>
The ORM framework I want to use is http://dataobjects.net/

- Jensen

On 01/17/2011 10:21 AM, Jensen Somers wrote:

>>
> The ORM framework I want to use is http://dataobjects.net/
>
> - Jensen

Hmm, sees you might have to be patient:) From the their manual:

Upcoming storage providers include:

     * Built-in file system database (i.e. regular embedded database)

Any bets on whether that is going to be Sqlite?

--
Adrian Klaver
adrian.klaver@gmail.com

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