linux-ext4 - Re: info about filesystem errors in /sys/fs/ext4/... ?

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:	Mon, 5 May 2014 07:59:19 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Lukáš Czerner <lczerner@...hat.com>
Cc:	Nikola Ciprich <nikola.ciprich@...uxbox.cz>,
	linux-ext4@...r.kernel.org
Subject: Re: info about filesystem errors in /sys/fs/ext4/... ?

On Mon, May 05, 2014 at 01:03:17PM +0200, Lukáš Czerner wrote:
> 
> However we might to go a step further, because I do not
> really like the idea of allowing to mount the file system with
> errors by default. It does not really make sense to me and I wonder
> whether someone actually intend to do it this way.

We would need to make an exception for the root file system, of
course.  And I've been receiving patches from folks who want to allow
e2fsck to be able to fix a mounted, read-only /usr partition, since
systemd is forcing folks to have to mount /usr read-only before it
will start, which means /usr needs to be mounted before e2fsck gets
started by systemd.

So that implies that we may need to have an exception for certain
non-root file systems as well, if we want to disallow mounting file
systems that have errors by default.  Or perhaps we should only
disallow read/write mounts of file systems that have errors without
some kind of override mount option.  Although I'm not sure we could
just start doing that by default without breaking some set of systems
and their current set of init scripts.

As far as determining whether or not a file system has errors, having
a /sys entry makes sense; although userspace could just read this out
of the ext2/3/4 superblock directly.

I'll note that internally inside Google, we've used multiple
mechanisms over time and for different use cases.  In some cases we've
scraped the system log files; in some cases we've used a hack that
redirected ext4_error() information into a custom semi-structured data
stream delivered via a netlink socket; and in some cases we've had a
userspace daemon parse the output of "dumpe2fs -h /dev/XXX".

Cheers,

					- 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