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: <20140505191557.GM22287@thunk.org> Date: Mon, 5 May 2014 15:15:57 -0400 From: Theodore Ts'o <tytso@....edu> To: Eric Sandeen <sandeen@...hat.com> Cc: Lukáš Czerner <lczerner@...hat.com>, Nikola Ciprich <nikola.ciprich@...uxbox.cz>, linux-ext4@...r.kernel.org Subject: Re: info about filesystem errors in /sys/fs/ext4/... ? For the record, since this was discussed on the ext4 weekly teleconference... The reason why I've been hesitant about allowing any file system to be checked by e2fsck while being mounted read-only is because of the following failure scenario: 1) The kernel discovers that a file system has been corrupted, so it marks the file system as being inconsistent and it remounts the file system read-only. 2) The user runs e2fsck on the file system, while it is still mounted read-only, and fixes it. 3) The kernel still has cached data structures with incorrect inode reference counts, etc. So when the user then remounts the file system read/write, the file system gets corrupted again, and the user suffers data loss. This could happen with the root file system as well, of course, but there is a big, large, scary message making it clear that you *MUST* reboot after repairing a corrupted root file system. The real issue is encouraging users from checking mounted file systems at all. One approach would be do to require a command-line option of the form --i-know-this-is-dangerous-and-I-could-lose-data, or some such. Apparently xfs does something like this, with a xfs_repair -d ('D' is for Dangerous). Another approach which Andreas Dilger suggested, and which we will likely use, is one where we snapshot the last fsck time from the superblock when the file system is mounted or remounted read-only. Then when the user tries to remount the file system read-write, if the last fsck time has been changed, we reject the r/w remount request. Regards, - 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