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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150911175551.GD31723@thunk.org>
Date:	Fri, 11 Sep 2015 13:55:51 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Chris Hunter <chris.hunter@...e.edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: e2fsck discrepancy with debugfs stat ?

On Thu, Sep 10, 2015 at 11:03:57PM -0400, Chris Hunter wrote:
> Are there scenarios where e2fsck will report a deleted/unused inode but
> debugfs is able to read the inode structure ?

When e2fsck reports that an inode is deleted/unused, it means that the
i_links_count field in the inode is zero.  If that happens, it's
possible that the blocks previously associated with inode have been
reassigned, and so may contain someone else's love letters, medical
records, etc., and so the ext4 file system will report a corruption,
and allow you to read the inode, and e2fsck assumes that the
appropriate resolution to the problem is to clear the directory entry.

(After all, you wouldn't want to accidentally commit a HIPPA
violation, when fines for violations range $100 to $50,000 per record,
would you?  Not to mention potentially getting lots of terrible Yelp
reviews.  :-)

> However when I run command debugfs -c -R "stat /O/0/d19/131249395" <DEV>, I
> can retrieve inode contents. Further debugfs "dump" will successfully pull
> the contents (980 bytes) of the file entry.

You can do anything with with debugfs.  Debugfs doesn't care if the
i_links_count field is zero, so it will happily return whatever might
be pointed to by that inode.

In terms of what might cause this, unless someone has been
manipulating file system structures using debugfs (for example,
"set_inode_field /O/0/d19/131249395 i_links_count 0"), it shouldn't
happen modulo hardware or software malfunctions / bugs.  For example,
if you are using a SSD which isn't power failure protected (most
consumer-grade SSD's aren't) after a power failure, even if the file
system is properly using cache flush commands, if the SSD isn't set up
to make sure the SSD's metadata is properly saved to stable storage
after a power failure, the underlying file system can get corrupted.

      	      	       	   	      	   	  - Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists