Linux Overlay Filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Christian Brauner <brauner@kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Amir Goldstein <amir73il@gmail.com>,
	Zorro Lang <zlang@kernel.org>
Cc: linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] src/vfs: probe O_TMPFILE support on the base mount in the idmapped tests
Date: Mon, 20 Jul 2026 18:15:31 +0930	[thread overview]
Message-ID: <fbfbafef-2b42-4f5e-ac8e-9c680a0be5ad@gmx.com> (raw)
In-Reply-To: <20260615-overlay-idmapped-vfstest-v1-1-c6b3b2228092@kernel.org>



在 2026/6/16 01:03, Christian Brauner 写道:
> openat_tmpfile_supported() in the idmapped mount tests probes O_TMPFILE
> on the idmapped mount (open_tree_fd) as the test's fsuid -- but that
> fsuid is not mapped by the idmapped mount under test, so it really asks
> "can this unmapped caller create a tmpfile through this idmap?" instead
> of "does the filesystem support O_TMPFILE?".
> 
> On overlayfs this is a false negative: the backing tmpfile ends up owned
> by an unmapped id, overlayfs opens it with O_NOATIME and may_open()
> returns -EPERM, so the tmpfile sub-tests are wrongly skipped.
> 
> O_TMPFILE support is a property of the filesystem, not of the idmapped
> mount or the caller's mapping. Probe info->t_dir1_fd, the base mount
> that the caller owns, exactly as the non-idmapped setgid tests already
> do. The probe then succeeds on every filesystem and the tmpfile
> sub-tests run as the mapped fsuid.
> 
> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

Reviewed-by: Qu Wenruo <wqu@suse.com>

Furthermore, since kernel commit 539dce114465 ("fs: refuse O_TMPFILE 
creation with an unmapped fsuid or fsgid"), even without overlayfs the 
involved tests will fail due to the extra checks.

So this is not only affecting overlayfs but all regular fses now.

I hope we can at least merge this one asap.

Thanks,
Qu

> ---
>   src/vfs/idmapped-mounts.c | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/src/vfs/idmapped-mounts.c b/src/vfs/idmapped-mounts.c
> index ed9992f9..8f8441c9 100644
> --- a/src/vfs/idmapped-mounts.c
> +++ b/src/vfs/idmapped-mounts.c
> @@ -3838,7 +3838,7 @@ int tcore_setgid_create_idmapped(const struct vfstest_info *info)
>   		goto out;
>   	}
>   
> -	supported = openat_tmpfile_supported(open_tree_fd);
> +	supported = openat_tmpfile_supported(info->t_dir1_fd);
>   
>   	pid = fork();
>   	if (pid < 0) {
> @@ -4014,7 +4014,7 @@ int tcore_setgid_create_idmapped_in_userns(const struct vfstest_info *info)
>   		goto out;
>   	}
>   
> -	supported = openat_tmpfile_supported(open_tree_fd);
> +	supported = openat_tmpfile_supported(info->t_dir1_fd);
>   
>   	pid = fork();
>   	if (pid < 0) {
> @@ -7733,7 +7733,7 @@ static int setgid_create_umask_idmapped(const struct vfstest_info *info)
>   		goto out;
>   	}
>   
> -	supported = openat_tmpfile_supported(open_tree_fd);
> +	supported = openat_tmpfile_supported(info->t_dir1_fd);
>   
>   	pid = fork();
>   	if (pid < 0) {
> @@ -7947,7 +7947,7 @@ static int setgid_create_umask_idmapped_in_userns(const struct vfstest_info *inf
>   		goto out;
>   	}
>   
> -	supported = openat_tmpfile_supported(open_tree_fd);
> +	supported = openat_tmpfile_supported(info->t_dir1_fd);
>   
>   	/*
>   	 * Below we verify that setgid inheritance for a newly created file or
> @@ -8181,7 +8181,7 @@ static int setgid_create_acl_idmapped(const struct vfstest_info *info)
>   		goto out;
>   	}
>   
> -	supported = openat_tmpfile_supported(open_tree_fd);
> +	supported = openat_tmpfile_supported(info->t_dir1_fd);
>   
>   	pid = fork();
>   	if (pid < 0) {
> @@ -8536,7 +8536,7 @@ static int setgid_create_acl_idmapped_in_userns(const struct vfstest_info *info)
>   		goto out;
>   	}
>   
> -	supported = openat_tmpfile_supported(open_tree_fd);
> +	supported = openat_tmpfile_supported(info->t_dir1_fd);
>   
>   	/*
>   	 * Below we verify that setgid inheritance for a newly created file or
> 


  parent reply	other threads:[~2026-07-20  8:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-15 15:33 [PATCH 0/2] Support overlayfs in the idmapped mount tests Christian Brauner
2026-06-15 15:33 ` [PATCH 1/2] src/vfs: probe O_TMPFILE support on the base mount in the idmapped tests Christian Brauner
2026-06-15 17:53   ` Amir Goldstein
2026-07-10  5:34   ` Christoph Hellwig
2026-07-20  8:45   ` Qu Wenruo [this message]
2026-06-15 15:33 ` [PATCH 2/2] src/vfs: skip whiteout-device fixtures on overlayfs Christian Brauner
2026-06-15 18:03   ` Amir Goldstein
2026-07-10  5:34     ` Christoph Hellwig
2026-07-10  5:33 ` [PATCH 0/2] Support overlayfs in the idmapped mount tests Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fbfbafef-2b42-4f5e-ac8e-9c680a0be5ad@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=zlang@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox