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: <20251105-abbaden-unmerklich-6682a021d5a8@brauner>
Date: Wed, 5 Nov 2025 12:54:10 +0100
From: Christian Brauner <brauner@...nel.org>
To: Al Viro <viro@...iv.linux.org.uk>
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 06:48:22PM +0000, Al Viro wrote:
> 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?

Maybe a flag but even then. I'm pretty sure that mount can just use
statmount() to figure out that someone is trying to mount the same fs
twice and simply abort. That should be close enough...