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 16:38:52 +0300
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Marco Stornelli <marco.stornelli@...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.

On Fri, 2012-08-24 at 15:20 +0200, Marco Stornelli wrote:
> 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.

May be. Or may be you are in situation that you really want all
processes top modifying anything in debugfs. This depends on the
"emergency" you deal with. You can always re-mount debugfs back to rw by
hands using something like:

	mount -t debufs -o remount,rw none /sys/kernel/debug

-- 
Best Regards,
Artem Bityutskiy

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)