Re: [PATCH v4] ext4: wipe ext4_dir_entry2 upon file deletion

[Theodore Ts'o]

On Fri, Jul 02, 2021 at 01:29:52PM +0000, Artem S. Tashkinov wrote:
> Hi,
> 
> I'm curious about the nature of this feature. Does it make restoring
> accidentally deleted files more difficult or even impossible? OK, data
> remains but the patch description makes it sound like all the metadata
> is being wiped completely.

It doesn't make any worse, but that's because ever since ext3 (e.g.,
since 2001), when we unlink a file, we endup zeroing i_blocks[] as
well as the indirect or extent tree blocks.  We *could* have fixed
this by special casing the path where the entire unlink fits inside
the current transaction, instead of always allowing for the
transaction to split across more than one transaction.

No one complained about the fact we were zero'ing the logical ->
physical block maps for two decades, by which I think we can assume
almost no one has tried used the "lsdel" + "link" hack in debugfs for
years and years.

> If it's the case, is it possible to make this new security feature user
> configurable? I'm OK with it being on by default but I'd be glad if
> there were a mount option to disable it.

We considered this, but given that all this would do is allow people
to recover the timestamps, user/group ownerships, etc., but not the
data blocks, it was deemed not to be worth the extra complexity.

If someone really wanted to allow undelete support, they could use the
various userspace solutions, or we *could* have an optional feature
which moves inodes whose link couint is about to go to zero into a
magic "trash can" directory, with some kind of automated auto-delete
mechanism when free blocks or free inodes all below some threshold, or
when free space falls below some threshold.  The trash can directory
would have to be readable only by root, in order to preserve security
when users delete files in a mode 0700 directory.  I'm not really
convinced it's worth it to implement such a thing, though....

	       	     	   	     	  - Ted