linux-ext4 - Re: [PATCH] ext4: always set inode of deleted entry to zero

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 15 May 2019 23:17:37 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Liu Song <fishland@...yun.com>
Cc:     adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, liu.song11@....com.cn
Subject: Re: [PATCH] ext4: always set inode of deleted entry to zero

On Wed, May 15, 2019 at 10:00:00PM +0800, Liu Song wrote:
> Although the deleted entry can not be seen by changing
> the rec_len of the parent directory entry. However we
> can piggyback set the entry's inode to 0. There is no
> harm and an entry with an inode of 0 means that the
> entry has been deleted and more reliable.
> 
> Signed-off-by: Liu Song <liu.song11@....com.cn>

What are the circumstances where this is "more reliable"?  In other
words, what problem are you trying to solve?  The fact that we don't
zero the inode number, but simply make the directory entry "disappear"
if possible is actually deliberate.

The goal was to give careless sytem administrators one last saving
throw (sorry, American English figure of speach; see [1] for an
explanation) against accidental mistakes, ifh they can shutdown their
system fast enough.

[1] https://en.wikipedia.org/wiki/Saving_throw

This doesn't actually work all that well these days, admittedly
because of how ext4_truncate works.  (See the debugfs man page for
lsdel for more details.)  However, I've always had the thought that if
someone wanted to implement a hack where all of the bitmap blocks that
would need to be zero could fit in a transaction, we wouldn't need to
update the extent tree blocks and indirect blocks, and could
significantly simplify the how many blocks might need to be modified
when deleting a file --- and make lsdel something that could work in
emergency circumstances again.

						- Ted