linux-kernel - Re: [RFC] [PATCH] vfs: remount all file-systems R/O on emergency remount.

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, 24 Aug 2012 15:20:39 +0200
From:	Marco Stornelli <marco.stornelli@...il.com>
To:	Artem Bityutskiy <dedekind1@...il.com>
CC:	Al Viro <viro@...IV.linux.org.uk>,
	Linux FS Maling List <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Maling List <linux-kernel@...r.kernel.org>,
	Alexander Stein <alexander.stein@...tec-electronic.com>
Subject: Re: [RFC] [PATCH] vfs: remount all file-systems R/O on emergency
 remount.

Il 24/08/2012 09:26, Artem Bityutskiy ha scritto:
> From: Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
>
> Currently the emergency remount (triggered by Sysrq-u) re-mounting only
> those file-systems R/O, which have an associated block device (sb->s_bdev).
> This does not work for file-systems like UBIFS and JFFS2 which work on top
> of MTD devices (character devices) and always have sb->s_bdev = NULL.
>
> This also does not work for tmpfs.
>
> Most probably the intention was to avoid re-mounting R/O file-systems like
> procfs, sysfs, cgroup, and debugfs. However, I do not really see why not
> to remount them R/O as well in case of emergency.
>
> This patch removes the 'sb->s_bdev != NULL' check from
> 'do_emergency_remount()', so _all_ file-systems will be re-mounted R/O.
>
> Tested in Fedora - all file-systems (ext4, ubifs, procfs, sysfs, cgroup, and
> debugfs) become R/O on Sysrq-u with this patch.
>
> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>

Does it make sense to remount r/o for example debugfs in this case? 
Maybe if there is something wrong I want enable something to catch debug 
info. Similar things for other pseudo-fs. Sure, the s_bdev seems a 
strong check. We could add a new flag to know if the emergency remount 
should be happen. It would give us the fs granularity, and maybe it 
could be turned on/off with the mount.

Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/