Re: how to securely delete the storage freed when a table is dropped?

> On Apr 13, 2018, at 10:48 AM, Jonathan Morgan <jonathan.morgan.007@gmail.com> wrote:
>
> For a system with information stored in a PostgreSQL 9.5 database, in which data stored in a table that is deleted
mustbe securely deleted (like shred does to files), and where the system is persistent even though any particular table
likelywon't be (so can't just shred the disks at "completion"), I'm trying to figure out my options for securely
deletingthe underlying data files when a table is dropped. 
>
> As background, I'm not a DBA, but I am an experienced implementor in many languages, contexts, and databases. I've
lookedonline and haven't been able to find a way to ask PostgreSQL to do the equivalent of shredding its underlying
filesbefore releasing them to the OS when a table is DROPped. Is there a built-in way to ask PostgreSQL to do this? (I
mightjust not have searched for the right thing - my apologies if I missed something) 
>
> A partial answer we're looking at is shredding the underlying data files for a given relation and its indexes
manuallybefore dropping the tables, but this isn't so elegant, and I'm not sure it is getting all the information from
thetables that we need to delete. 
>
> We also are looking at strategies for shredding free space on our data disk - either running a utility to do that, or
periodicallyreplicating the data volume, swapping in the results of the copy, then shredding the entire volume that was
thesource so its "free" space is securely overwritten in the process. 
>
> Are we missing something? Are there other options we haven't found? If we have to clean up manually, are there other
placeswe need to go to shred data than the relation files for a given table, and all its related indexes, in the
database'sfolder? Any help or advice will be greatly appreciated. 

Just "securely" deleting the files won't help much, as you'll leave data in spare space on the filesystem, in
filesystemjournals and so on. 

Maybe put the transient tables an indexes in their own tablespace on their own filesystem, periodically move them to
anothertablespace and wipe the first one's filesystem (either physically or forgetting the key for an encrypted FS)?
That'dleave you with just the WAL data to deal with. 

Seems like a slightly odd requirement, though. What's your threat model?

Cheers,
  Steve