linux-kernel - Re: [PATCH] mount: fix duplicate mounts using the new mount API

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] [day] [month] [year] [list]

Message-ID: <20251031184822.GC2441659@ZenIV>
Date: Fri, 31 Oct 2025 18:48:22 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Christian Brauner <brauner@...nel.org>
Cc: GuangFei Luo <luogf2025@....com>, jack@...e.cz,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] mount: fix duplicate mounts using the new mount API

On Fri, Oct 31, 2025 at 01:54:27PM +0100, Christian Brauner wrote:

> > > I agree that it's a regression in mount(8) conversion to new API, but this
> > > is not a fix.
> > Thanks for the review. Perhaps fixing this in |move_mount| isn't the best
> > approach, and I don’t have a good solution yet.
> 
> Sorry, no. This restriction never made any sense in the old mount api
> and it certainly has no place in the new mount api. And it has been
> _years_ since the new mount api was released. Any fix is likely to break
> someone else that's already relying on that working.

Not quite...  I agree that it makes little sense to do that on syscall level,
but conversion of mount(8) to new API is a different story - that's more recent
than the introduction of new API itself and it does create a regression on
the userland side.

IIRC, the original rationale had been "what if somebody keeps clicking on
something in some kind of filemangler inturdface and gets a pile of overmounts
there?", but however weak that might be, it is an established behaviour of
mount(2), with userland callers of mount(2) expecting that semantics.

Blind conversion to new API has changed userland behaviour.  I would argue
that it's a problem on the userland side, and the only question kernel-side
is whether there is something we could provide to simplify the life of those
who do such userland conversions.  A move_mount(2) flag, perhaps, defaulting
to what we have move_mount(2) do now?