Re: BUG #3232: Regression: pgsql server startup problem with encrypted partitions - Mailing list pgsql-bugs

From Magnus Hagander
Subject Re: BUG #3232: Regression: pgsql server startup problem with encrypted partitions
Date
Msg-id 20070418073618.GB20431@svr2.hagander.net
Whole thread Raw
In response to BUG #3232: Regression: pgsql server startup problem with encrypted partitions  ("Carsten" <fcarsten@tpg.com.au>)
List pgsql-bugs
On Mon, Apr 16, 2007 at 11:56:29PM +0000, Carsten wrote:
>
> The following bug has been logged online:
>
> Bug reference:      3232
> Logged by:          Carsten
> Email address:      fcarsten@tpg.com.au
> PostgreSQL version: 8.2.3
> Operating system:   Windows XP SP 2
> Description:        Regression: pgsql server startup problem with encrypted
> partitions
> Details:
>
> I am running the following scenario:
>
> * Windows XP SP 2
> * Postgres 8.2.3 installed on a normal Windows partition
> * One highly sensitive database on a seperate table space which is located
> on a TureCrypt partition
> * The TrueCrypt partition only can be mounted after I log into the machine
> (as I have to enter the password)
>
> In the version of PostgreSQL which I was using previously (don't remember
> version number) this scenario worked fine. As long as I didn't try to access
> a database on the encrypted partition before mounting it the pgsql server
> was happy.

That was most likely just pure luck.

> In current version this no longer works. I have to manually restart the
> pgsql server after mounting the encyprted partition to access the database
> on it.
>
> Were there any changes which made the pgsql server stricter in requiring
> that all table-spaces exist on start-up? If yes, any chance of reversing
> this to support databases on encrypted partitions or removable devices?

The PostgreSQL startup process can access pretty much *any* file, depending
on circumstances. I don't see how we can make a guarantee about that.

We do support databases on encrypted partitions or removable drive - but
sticking *parts* of them there and just hopeing that the drive will be
there by the time you access just that part is not a very stable thing to
do. Keep the whole db on it, and make sure it's available before you start
PostgreSQL, andi t should work fine.
(This is simlar to NFS mounted data directories, which do work but only if
you're careful)

Now, you might want to consider using EFS for your encryption. When
properly set up, you won't need to input your password to get it going,
which in turn means that it can start up properly. If you really want the
password input part, set it up so PostgreSQL is started after TrueCrypt.

//Magnus

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #3232: Regression: pgsql server startup problem with encrypted partitions
Next
From: Russell Smith
Date:
Subject: Re: Grantor name gets lost when grantor role dropped