Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> "asaba.takanori@fujitsu.com" <asaba.takanori@fujitsu.com> writes:
> > I want to add the feature to erase data so that it cannot be restored
> > because it prevents attackers from stealing data from released data area.
>
> I think this is fairly pointless, unfortunately.
I disagree- it's a feature that's been asked for multiple times and does
have value in some situations.
> Dropping or truncating tables is as much as we can do without making
> unwarranted assumptions about the filesystem's behavior. You say
> you want to zero out the files first, but what will that accomplish
> on copy-on-write filesystems?
What about filesystems which are not copy-on-write though?
> Even granting that zeroing our storage files is worth something,
> it's not worth much if there are more copies of the data elsewhere.
Backups are not our responsibility to worry about, or, at least, it'd be
an independent feature if we wanted to add something like this to
pg_basebackup, and not something the initial feature would need to worry
about.
> And any well-run database is going to have backups, or standby servers,
> or both. There's no way for the primary node to force standbys to erase
> themselves (and it'd be a different sort of security hazard if there
> were).
A user can't "force" PG to do anything more than we can "force" a
replica to do something, but a user can issue a request to a primary and
that primary can then pass that request along to the replica as part of
the WAL stream.
> Also to the point: if your assumption is that an attacker has access
> to the storage medium at a sufficiently low level that they can examine
> previously-deleted files, what's stopping them from reading the data
> *before* it's deleted?
This argument certainly doesn't make any sense- who said they had access
to the storage medium at a time before the files were deleted? What if
they only had access after the files were zero'd? When you consider the
lifetime of a storage medium, it's certainly a great deal longer than
the length of time that a given piece of sensitive data might reside on
it.
> So I think doing anything useful in this area is a bit outside
> Postgres' remit. You'd need to be thinking at an operating-system
> or hardware level.
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.
Thanks,
Stephen
