Re: [HACKERS] WIP: Data at rest encryption - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: [HACKERS] WIP: Data at rest encryption
Date
Msg-id 20170614090426.GA7249@e733.localdomain
Whole thread Raw
In response to Re: [HACKERS] WIP: Data at rest encryption  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] WIP: Data at rest encryption
Re: [HACKERS] WIP: Data at rest encryption
List pgsql-hackers
Hi Ants,

On Tue, Jun 13, 2017 at 09:07:49AM -0400, Peter Eisentraut wrote:
> On 6/12/17 17:11, Ants Aasma wrote:
> > I'm curious if the community thinks this is a feature worth having?
> > Even considering that security experts would classify this kind of
> > encryption as a checkbox feature.
>
> File system encryption already exists and is well-tested.  I don't see
> any big advantages in re-implementing all of this one level up.  You
> would have to touch every single place in PostgreSQL backend and tool
> code where a file is being read or written.  Yikes.

I appreciate your work, but unfortunately I must agree with Peter.

On Linux you can configure the full disc encryption using LUKS /
dm-crypt in like 5 minutes [1]. On FreeBSD you can do the same using
geli [2]. In my personal opinion PostgreSQL is already complicated
enough. A few companies that hired system administrators that are too
lazy to read two or three man pages is not a reason to re-implement file
system encryption (or compression, or mirroring if that matters) in any
open source RDBMS.

[1] http://eax.me/dm-crypt/
[2] http://eax.me/freebsd-geli/

--
Best regards,
Aleksander Alekseev

pgsql-hackers by date:

Previous
From: Marina Polyakova
Date:
Subject: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()