"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.
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?
Even granting that zeroing our storage files is worth something,
it's not worth much if there are more copies of the data elsewhere.
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).
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?
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.
regards, tom lane
