Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > "asaba.takan...@fujitsu.com" <asaba.takan...@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
signature.asc
Description: PGP signature