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
| ||
|
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