Destroying data when exporting pool does not seem to actually destroy data

[scurrier]

I have a pool I wanted to use for backup. The root dataset was encrypted but I accidentally didn't encrypt the child data sets under it because of not understanding how replication works. So, I needed to wipe the disk and start over, because it had unencrypted data written to it which could not be guaranteed to be overwritten upon recreation.

I exported a pool and selected the option to destroy the data. As expected, I was prompted to type the pool name to confirm. Upon execution, the pool was exported, several steps flew by and one of them was about destroying the data. On the destroying data step, the overall progress bar showed 80%. I wondered how long it was going to show the dialog while it wiped the data. The pool had several terabytes so it would definitely take hours. Then, mere seconds after starting the whole operation started, it appeared to finish and stated "Successfully exported/disconnected '<poolname>'. All data on that pool was destroyed."

Uhm, I doubt it. If the data on the disk had all been encrypted, I think this could be valid because destroying the encryption key is practically equivalent to destroying the data, so it could be completed in a very short time. But this disk had terabytes of unencrypted datasets under the root pool dataset. So there's no way it wiped it all in seconds.

I am going to wipe the disk manually, but I thought I'd post on the forums to see if I am missing anything obvious. Otherwise, it seems clear that this is a bug, maybe one where the devs didn't handle the case of unencrypted datasets under an encrypted pool dataset.

It should go without saying that assuring the user that data was destroyed when it actually wasn't is a big security issue.

 

[chuck32]

It should go without saying that assuring the user that data was destroyed when it actually wasn't is a big security issue.

Of course, but did you actually verify that the data indeed was not destroyed?

Also destroying data must not necessarily mean securily wiping data. May be a wording issue. At best it may turn out, yes the data is destroyed but not unrecoverable. In that case, if someone confirms I'd take your concerns and and suggest the UI / documentation is updated to reflect what destroying really means.

 

[scurrier]

Of course, but did you actually verify that the data indeed was not destroyed?

How do you recommend doing that? I am concerned that the data is still there even if it's not mountable, such that a knowledgeable person could recover it. It was several TB unencrypted and could not have possibly been overwritten in seconds. So it seems either the GUI indicator about encryption was wrong or the data was not truly destroyed.

But I am open to suggestions.

 

[scurrier]

Oops, just remembered I am already wiping the disks manually so I won't be able to check anything. Sorry.

 

[AlexGG]

I am concerned that the data is still there even if it's not mountable

This is correct. The unencrypted version can (in most cases) be recovered unless the drives are explicitly wiped afterward. I suspect (but never tested) that the encrypted version can be recovered too given the password.

 

[scurrier]

This is correct. The unencrypted version can (in most cases) be recovered unless the drives are explicitly wiped afterward. I suspect (but never tested) that the encrypted version can be recovered too given the password.

Would you agree, then, that this is a bug?

 

[cobrakiller58]

Not a bug in my books, there are specialized programs that corporations use to destroy data on drives before disposal. Most file systems just delete boot records and move on.

 

[AlexGG]

Would you agree, then, that this is a bug?

No, not really. I would normally associate "destroy" with "throw away into a trashcan", and "securely destroy/delete/erase" with secure erase. I mean, I do not expect anything to be a secure erase unless it is explicitly stated as such. I view it as maybe wrong wording, which maybe should be changed or a notice written, but even this may be overkill.

Anyone who wants (or requires) secure erase has their favorite (or certified, depending on the requirements) methods to securely erase the data anyway. Implementing the whole secure erase thing, which is a specialized field, I don't think it is in the domain of iX.

 

[scurrier]

I am surprised by the difference of opinion.

Nerd fight with me?

Here's the dialog one sees before the operation. Note the text I highlighted in yellow. "Data...can be destroyed by setting the Destroy data option." It also says (but I forgot to highlight), "Destroy data on this pool?" Two mentions of "destroy" in association with data.

To me, the specific words matter and "destroy" precisely means it's irretrievably gone. Yes, "securely destroyed" is more intense and specific, but "destroy" still means what it means. It didn't say "deleted", "removed", "unmounted", "detached", "exported", or other weaker terms. It says "data" with its plain meaning of data and not in any reference to a "dataset." It does not say "destroy" in reference to the misnomer zfs command that does not actually destroy, "zfs destroy." It says the data will be destroyed.

The final confirmation dialog said, "the data was destroyed". A third association between "data" and "destroy."

I would like to know your opinions about how this is not very clearly saying that the data will be destroyed, i.e. irretrievably gone.

 

[AlexGG]

Nerd fight with me?

To me, the specific words matter and "destroy" precisely means it's irretrievably gone.

To me, "destroy" means "you will not be able to use it", rather than "irretrievably gone".

Anyway, if you want to file a bug report, go right ahead. It is not like TrueNAS will get worse if the wording is changed.