Re: Complete data erasure - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Complete data erasure
Date
Msg-id 20200115163207.GO3195@tamriel.snowman.net
Whole thread Raw
In response to Re: Complete data erasure  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses RE: Complete data erasure  ("asaba.takanori@fujitsu.com" <asaba.takanori@fujitsu.com>)
List pgsql-hackers
Greetings,

* Tomas Vondra (tomas.vondra@2ndquadrant.com) wrote:
> On Wed, Jan 15, 2020 at 10:23:22AM -0500, Stephen Frost wrote:
> >I disagree entirely.  If the operating system and hardware level provide
> >a way for this to work, which is actually rather common when you
> >consider that ext4 is an awful popular filesystem where this would work
> >just fine with nearly all traditional hardware underneath it, then we're
> >just blocking enabling this capability for no justifiably reason.
>
> Not sure. I agree the goal (securely discarding data) is certainly
> worthwile, although I suspect it's just of many things you'd need to
> care about. That is, there's probably a million other things you'd need
> to worry about (logs, WAL, CSV files, temp files, ...), so with actually
> sensitive data I'd expect people to just dump/load the data into a clean
> system and rebuild the old one (zero drives, ...).

Of course there's other things that one would need to worry about, but
saying this isn't useful because PG isn't also scanning your entire
infrastructure for CSV files that have this sensitive information isn't
a sensible argument.

I agree that there are different levels of sensitive data- and for many,
many cases what is being proposed here will work just fine, even if that
level of sensitive data isn't considered "actually sensitive data" by
other people.

> But let's assume it makes sense - is this really the right solution? I
> think what I'd prefer is encryption + rotation of the keys. Which should
> work properly even on COW filesystems, the performance impact is kinda
> low and amortized etc. Of course, we're discussing built-in encryption
> for quite a bit of time.

In some cases that may make sense as an alternative, in other situations
it doesn't.  In other words, I disagree that what you're proposing is
just a different implementation of the same thing (which I'd be happy to
discuss), it's an entirely different feature with different trade-offs.

I'm certainly on-board with the idea of having table level and column
level encryption to facilitate an approach like this, but I disagree
strongly that we shouldn't have this simple "just overwrite the data a
few times" because we might, one day, have useful in-core encryption or
even that, even if we had it, that we should tell everyone to use that
instead of providing this capability.  I don't uninstall 'shread' when I
install 'gpg' on my system.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Complete data erasure
Next
From: Tom Lane
Date:
Subject: Re: Rearranging ALTER TABLE to avoid multi-operations bugs