Messages in this thread | | | Date | Fri, 2 Jul 2021 12:01:11 -0400 | From | "Theodore Ts'o" <> | Subject | Re: [PATCH v4] ext4: wipe ext4_dir_entry2 upon file deletion |
| |
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
| |