On Tue, Oct 1, 2019 at 11:54:26AM -0400, Bruce Momjian wrote:
> On Tue, Oct 1, 2019 at 03:43:05PM +0200, Tomas Vondra wrote:
> > Plus it allows features you can't easily achieve with fs encryption,
> > because the filesystem only sees opaque data files. So having keys per
> > database/user/... is easier from within the database.
>
> Yes, but we will not be doing that for the first release because of the
> complexity related to handling this in WAL and requiring crash recovery
> to be able to unlock all the keys for replay. I personally think that
> database/user/... keys are best done at the SQL level, with proper
> locking. pgcryptokey (http://momjian.us/download/pgcryptokey/) is an
> example of that.
Just to give more detail. Initially, there was a desire to store keys
in only one place, either in the file system or in database tables.
However, it became clear that the needs of booting the server and crash
recovery required file system keys, and per-user/db keys were best done
at the SQL level, so that indexing can be used, and logical dumps
contain the locked keys. SQL-level storage allows databases to be
completely independent of other databases in terms of key storage and
usage.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +