RE: Complete data erasure

Hello Stephen,

Thank you for comment.

From: Stephen Frost <sfrost(at)snowman(dot)net>
> Greetings,
>
> * asaba(dot)takanori(at)fujitsu(dot)com (asaba(dot)takanori(at)fujitsu(dot)com) wrote:
> > This feature erases data area just before it is returned to the OS (“erase”
> means that overwrite data area to hide its contents here)
> > because there is a risk that the data will be restored by attackers if it is returned
> to the OS without being overwritten.
> > The erase timing is when DROP, VACUUM, TRUNCATE, etc. are executed.
>
> Looking at this fresh, I wanted to point out that I think Tom's right-
> we aren't going to be able to reasonbly support this kind of data
> erasure on a simple DROP TABLE or TRUNCATE.
>
> > I want users to be able to customize the erasure method for their security
> policies.
>
> There's also this- but I think what it means is that we'd probably have
> a top-level command that basically is "ERASE TABLE blah;" or similar
> which doesn't operate during transaction commit but instead marks the
> table as "to be erased" and then perhaps "erasure in progress" and then
> "fully erased" (or maybe just back to 'normal' at that point). Making
> those updates will require the command to perform its own transaction
> management which is why it can't be in a transaction itself but also
> means that the data erasure process doesn't need to be done during
> commit.
>
> > My idea is adding a new parameter erase_command to postgresql.conf.
>
> Yeah, I don't think that's really a sensible option or even approach.

I think erase_command can also manage the state of a table.
The exit status of a configured command shows it.( 0 is "fully erased" or "normal", 1 is "erasure in progress")
erase_command is executed not during a transaction but when unlink() is executed.
(for example, after a transaction that has done DROP TABLE)
I think that this shows " to be erased ".

> > When erase_command is set, VACUUM does not truncate a file size to non-zero
> > because it's safer for users to return the entire file to the OS than to return part
> of it.
>
> There was discussion elsewhere about preventing VACUUM from doing a
> truncate on a file because of the lock it requires and problems with
> replicas.. I'm not sure where that ended up, but, in general, I don't
> think this feature and VACUUM should really have anything to do with
> each other except for the possible case that a user might be told to
> configure their system to not allow VACUUM to truncate tables if they
> care about this case.

I think that if ftruncate(fd, 0) is executed in VACUUM,
data area allocated to a file is returned to the OS, so that area must be overwritten.

> As mentioned elsewhere, you do also have to consider that the sensitive
> data will end up in the WAL and on replicas. I don't believe that means
> this feature is without use, but it means that users of this feature
> will also need to understand and be able to address WAL and replicas
> (along with backups and such too, of course).

I see.
I can't think of it right away, but I will deal with it.

Sorry for my late reply.
It takes time to understand email from you because I'm a beginner.
Please point out any mistakes.

Regards,

--
Takanori Asaba