Message-ID: <20250819-erhitzen-knacken-e4d52248ca3e@brauner>
Date: Tue, 19 Aug 2025 10:31:35 +0200
From: Christian Brauner <brauner@...nel.org>
To: Aleksa Sarai <cyphar@...har.com>
Cc: Askar Safin <safinaskar@...omail.com>, alx@...nel.org, 
	dhowells@...hat.com, g.branden.robinson@...il.com, jack@...e.cz, 
	linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-man@...r.kernel.org, mtk.manpages@...il.com, viro@...iv.linux.org.uk, 
	Ian Kent <raven@...maw.net>, autofs mailing list <autofs@...r.kernel.org>
Subject: Re: [PATCH v3 00/12] man2: document "new" mount API

On Mon, Aug 18, 2025 at 02:16:04AM +1000, Aleksa Sarai wrote:
> On 2025-08-17, Askar Safin <safinaskar@...omail.com> wrote:
> > I noticed that you changed docs for automounts. So I dig into
> > automounts implementation. And I found a bug in openat2. If
> > RESOLVE_NO_XDEV is specified, then name resolution doesn't cross
> > automount points (i. e. we get EXDEV), but automounts still happen! I
> > think this is a bug. Bug is reproduced in 6.17-rc1. In the end of this
> > mail you will find reproducer. And miniconfig.
> 
> Yes, this is a bug -- we check LOOKUP_NO_XDEV after traverse_mounts()
> because we want to error out if we actually jumped to a different mount.
> We should probably be erroring out in follow_automount() as well, and I
> missed this when I wrote openat2().
> 
> openat2() also really needs RESOLVE_NO_AUTOMOUNT (and probably
> RESOLVE_NO_DOTDOT as well as some other small features). I'll try to
> send something soon.
> 
> > Are automounts actually used? Is it possible to deprecate or
> > remove them? It seems for me automounts are rarely tested obscure
> > feature, which affects core namei code.
> 
> I use them for auto-mounting NFS shares on my laptop, and I'm sure there
> are plenty of other users. They are little bit funky but I highly doubt
> they are "unused". Howells probably disagrees in even stronger terms.
> Most distributions provide autofs as a supported package (I think it
> even comes pre-installed for some distros).
> 
> They are not tested by fstests AFAICS, but that's more of a flaw in
> fstests (automount requires you to have a running autofs daemon, which
> probably makes testing it in fstests or selftests impractical) not the
> feature itself.
> 
> > This reproducer is based on "tracing" automount, which
> > actually *IS* already deprecated. But automount mechanism
> > itself is not deprecated, as well as I know.
> 
> The automount behaviour of tracefs is different to the general automount
> mechanism which is managed by userspace with the autofs daemon. I don't
> know the history behind the deprecation, but I expect that it was
> deprecated in favour of configuring it with autofs (or just enabling it
> by default).
> 
> > Also, I did read namei code, and I think that
> > options AT_NO_AUTOMOUNT, FSPICK_NO_AUTOMOUNT, etc affect
> > last component only, not all of them. I didn't test this yet.
> > I plan to test this within next days.
> 
> No, LOOKUP_AUTOMOUNT affects all components. I double-checked this with
> Christian.

Hm? I was asking the question in the chat because I was unsure and not
in front of a computer you then said that it does affect all components. :)

> 
> You would think that it's only the last component (like O_DIRECTORY,
> O_NOFOLLOW, AT_SYMLINK_{,NO}FOLLOW) but follow_automount() is called for
> all components (i.e., as part of step_into()). It hooks into the regular
> lookup flow for mountpoints.
> 
> Yes, it is quite funky that AT_NO_AUTOMOUNT is the only AT_* flag that
> works this way -- hence why I went with a different RESOLVE_* namespace
> for openat2() (which _always_ act on _all_ components).
> 
> -- 
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> https://www.cyphar.com/

Powered by blists - more mailing lists