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: <ZPsMmjFXGFmdRP+d@duo.ucw.cz>
Date:   Fri, 8 Sep 2023 13:59:22 +0200
From:   Pavel Machek <pavel@....cz>
To:     Jan Kara <jack@...e.cz>
Cc:     Mikulas Patocka <mpatocka@...hat.com>,
        Christian Brauner <brauner@...nel.org>,
        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 2023-09-07 11:44:57, Jan Kara wrote:
> On Wed 06-09-23 18:52:39, Mikulas Patocka wrote:
> > On Wed, 6 Sep 2023, Christian Brauner wrote:
> > > On Wed, Sep 06, 2023 at 06:01:06PM +0200, Mikulas Patocka wrote:
> > > > > > BTW. what do you think that unmount of a frozen filesystem should properly 
> > > > > > do? Fail with -EBUSY? Or, unfreeze the filesystem and unmount it? Or 
> > > > > > something else?
> > > > > 
> > > > > In my opinion we should refuse to unmount frozen filesystems and log an
> > > > > error that the filesystem is frozen. Waiting forever isn't a good idea
> > > > > in my opinion.
> > > > 
> > > > But lvm may freeze filesystems anytime - so we'd get randomly returned 
> > > > errors then.
> > > 
> > > So? Or you might hang at anytime.
> > 
> > lvm doesn't keep logical volumes suspended for a prolonged amount of time. 
> > It will unfreeze them after it made updates to the dm table and to the 
> > metadata. So, it won't hang forever.
> > 
> > I think it's better to sleep for a short time in umount than to return an 
> > error.
> 
> I think we've got too deep down into "how to fix things" but I'm not 100%
> 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? 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).

Umm. No? I admin my own systems; I'm responsible for my
userspace. Maybe I'm in single user mode.

Noone writes to my block devices without my permissions.

By mount, I give such permission to the kernel. By umount, I take
such permission away.

There's nothing flaky about that. Kernel is simply buggy. Fix it.

[Remember that "you should umount before disconnecting USB devices to
prevent data corruption"? How is that working with kernel writing to
devices after umount?]

Best regards,
									Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

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