Re: [HACKERS] WIP: Data at rest encryption

Поиск
Список
Период
Сортировка
От Aleksander Alekseev
Тема Re: [HACKERS] WIP: Data at rest encryption
Дата
Msg-id 20170614090426.GA7249@e733.localdomain
обсуждение исходный текст
Ответ на Re: [HACKERS] WIP: Data at rest encryption  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] WIP: Data at rest encryption  (Kenneth Marshall <ktm@rice.edu>)
Re: [HACKERS] WIP: Data at rest encryption  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Marina Polyakova
Дата:
Сообщение: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()