From: "Theodore Ts'o" <tytso@mit.edu>
To: "Artem S. Tashkinov" <aros@gmx.com>
Cc: linux-kernel@vger.kernel.org, leah.rumancik@gmail.com
Subject: Re: [PATCH v4] ext4: wipe ext4_dir_entry2 upon file deletion
Date: Fri, 2 Jul 2021 12:01:11 -0400 [thread overview]
Message-ID: <YN84R5GJrv5pvDuj@mit.edu> (raw)
In-Reply-To: <b99d8632-6e3d-b557-0ca4-7416a9d818d5@gmx.com>
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
prev parent reply other threads:[~2021-07-02 16:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 13:29 [PATCH v4] ext4: wipe ext4_dir_entry2 upon file deletion Artem S. Tashkinov
2021-07-02 16:01 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YN84R5GJrv5pvDuj@mit.edu \
--to=tytso@mit.edu \
--cc=aros@gmx.com \
--cc=leah.rumancik@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox