linux-ext4 - Re: e2fsck discrepancy with debugfs stat ?

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]

Date:	Fri, 11 Sep 2015 15:59:50 -0400
From:	Chris Hunter <chris.hunter@...e.edu>
To:	linux-ext4@...r.kernel.org
Subject: Re: e2fsck discrepancy with debugfs stat ?

Hi Theodore, Thanks for the reply.

Most of the e2fsck errors appear to have been uncommitted journal 
transactions. After stopping filesystem activity (hopefully to clear 
journal) a second dry-run e2fsck produced a much shorter list of errors.

FYI, There was an entry "Links: 1  Blockcount: 8" reported by debugfs 
"stat" command is that same as i_links_count field ?

thanks,
chris hunter
chris.hunter@...e.edu

On 09/11/2015 01:55 PM, Theodore Ts'o wrote:
> 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