From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Data at rest encryption |
Date: | 2017-06-13 20:10:34 |
Message-ID: | 20170613201034.GT13873@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 13, 2017 at 04:08:29PM -0400, Peter Eisentraut wrote:
> On 6/13/17 15:51, Bruce Momjian wrote:
> > Isn't the leakage controlled by OS permissions, so is it really leakage,
> > i.e., if you can see the leakage, you probably have bypassed the OS
> > permissions and see the key and data anyway.
>
> One scenario (among many) is when you're done with the disk. If the
> content was fully encrypted, then you can just throw it into the trash
> or have your provider dispose of it or reuse it. If not, then,
> depending on policy, you will have to physically obtain it and burn it.
Oh, I see your point --- db-level encryption stores the file system as
mountable on the device, while it is not with storage-level encryption
--- got it.
--
Bruce Momjian <bruce(at)momjian(dot)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 +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-13 20:23:39 | Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.) |
Previous Message | Peter Eisentraut | 2017-06-13 20:08:29 | Re: WIP: Data at rest encryption |