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  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" <>
To:     Liu Song <>
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 <>

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.


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

Powered by blists - more mailing lists