linux-kernel - Re: [PATCH] fix writing to the filesystem after unmount

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]

Message-ID: <20230908073244.wyriwwxahd3im2rw@quack3>
Date:   Fri, 8 Sep 2023 09:32:44 +0200
From:   Jan Kara <jack@...e.cz>
To:     Mikulas Patocka <mpatocka@...hat.com>
Cc:     Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Zdenek Kabelac <zkabelac@...hat.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        dm-devel@...hat.com, Christoph Hellwig <hch@....de>,
        "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: [PATCH] fix writing to the filesystem after unmount

On Thu 07-09-23 14:04:51, Mikulas Patocka wrote:
> 
> 
> On Thu, 7 Sep 2023, Christian Brauner wrote:
> 
> > > I think we've got too deep down into "how to fix things" but I'm not 100%
> > 
> > We did.
> > 
> > > sure what the "bug" actually is. In the initial posting Mikulas writes "the
> > > kernel writes to the filesystem after unmount successfully returned" - is
> > > that really such a big issue?
> 
> I think it's an issue if the administrator writes a script that unmounts a 
> filesystem and then copies the underyling block device somewhere. Or a 
> script that unmounts a filesystem and runs fsck afterwards. Or a script 
> that unmounts a filesystem and runs mkfs on the same block device.

Well, e.g. e2fsprogs use O_EXCL open so they will detect that the filesystem
hasn't been unmounted properly and complain. Which is exactly what should
IMHO happen.

> > > Anybody else can open the device and write to it as well. Or even 
> > > mount the device again. So userspace that relies on this is kind of 
> > > flaky anyway (and always has been).
> 
> It's admin's responsibility to make sure that the filesystem is not 
> mounted multiple times when he touches the underlying block device after 
> unmount.

What I wanted to suggest is that we should provide means how to make sure
block device is not being modified and educate admins and tool authors
about them. Because just doing "umount /dev/sda1" and thinking this means
that /dev/sda1 is unused now simply is not enough in today's world for
multiple reasons and we cannot solve it just in the kernel.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR