linux-kernel - Re: [PATCH v3 00/12] man2: document "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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2025-08-17.1755446479-rotten-curled-charms-robe-vWOBH5@cyphar.com>
Date: Mon, 18 Aug 2025 02:16:04 +1000
From: Aleksa Sarai <cyphar@...har.com>
To: Askar Safin <safinaskar@...omail.com>
Cc: alx@...nel.org, brauner@...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 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.

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/

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