linux-kernel - Re: [PATCH 2/2] autofs: dont trigger mount if it cant succeed

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: <20251114-rechnen-variieren-aaeb36bb57a0@brauner>
Date: Fri, 14 Nov 2025 12:44:23 +0100
From: Christian Brauner <brauner@...nel.org>
To: Ian Kent <raven@...maw.net>
Cc: Al Viro <viro@...iv.linux.org.uk>, 
	Kernel Mailing List <linux-kernel@...r.kernel.org>, autofs mailing list <autofs@...r.kernel.org>, 
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 2/2] autofs: dont trigger mount if it cant succeed

On Fri, Nov 14, 2025 at 07:49:53AM +0800, Ian Kent wrote:
> On 13/11/25 21:19, Christian Brauner wrote:
> > On Thu, Nov 13, 2025 at 08:14:36AM +0800, Ian Kent wrote:
> > > On 12/11/25 19:01, Christian Brauner wrote:
> > > > On Tue, Nov 11, 2025 at 08:27:42PM +0800, Ian Kent wrote:
> > > > > On 11/11/25 18:55, Christian Brauner wrote:
> > > > > > On Tue, Nov 11, 2025 at 10:24:35AM +0000, Al Viro wrote:
> > > > > > > On Tue, Nov 11, 2025 at 11:19:59AM +0100, Christian Brauner wrote:
> > > > > > > 
> > > > > > > > > +	sbi->owner = current->nsproxy->mnt_ns;
> > > > > > > > ns_ref_get()
> > > > > > > > Can be called directly on the mount namespace.
> > > > > > > ... and would leak all mounts in the mount tree, unless I'm missing
> > > > > > > something subtle.
> > > > > > Right, I thought you actually wanted to pin it.
> > > > > > Anyway, you could take a passive reference but I think that's nonsense
> > > > > > as well. The following should do it:
> > > > > Right, I'll need to think about this for a little while, I did think
> > > > > 
> > > > > of using an id for the comparison but I diverged down the wrong path so
> > > > > 
> > > > > this is a very welcome suggestion. There's still the handling of where
> > > > > 
> > > > > the daemon goes away (crash or SIGKILL, yes people deliberately do this
> > > > > 
> > > > > at times, think simulated disaster recovery) which I've missed in this
> > > > Can you describe the problem in more detail and I'm happy to help you
> > > > out here. I don't yet understand what the issue is.
> > > I thought the patch description was ok but I'll certainly try.
> > I'm sorry, we're talking past each other: I was interested in your
> > SIGKILL problem when the daemon crashes. You seemed to say that you
> > needed additional changes for that case. So I'm trying to understand
> > what the fundamental additional problem is with a crashing daemon that
> > would require additional changes here.
> 
> Right, sorry.
> 
> It's pretty straight forward.
> 
> 
> If the daemon is shutdown (or killed summarily) and there are busy
> 
> mounts left mounted then when started again they are "re-connected to"
> 
> by the newly running daemon. So there's a need to update the mnt_ns_id in
> 
> the ioctl that is used to set the new pipefd.
> 
> 
> I can't provide a patch fragment because I didn't realise the id in
> ns_common

Before that you can grab it from the mount namespace directly from the
mntns->seq field.