Linux userland API discussions
 help / color / mirror / Atom feed
From: Li Chen <me@linux.beauty>
To: Christian Brauner <brauner@kernel.org>,
	Kees Cook <kees@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kselftest@vger.kernel.org, x86@kernel.org,
	Arnd Bergmann <arnd@arndb.de>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Jan Kara <jack@suse.cz>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>, Li Chen <me@linux.beauty>
Subject: [RFC PATCH v1 10/13] exec: require absolute paths for path-created templates
Date: Thu, 28 May 2026 17:52:31 +0800	[thread overview]
Message-ID: <20260528095235.2491226-11-me@linux.beauty> (raw)
In-Reply-To: <20260528095235.2491226-1-me@linux.beauty>

Path-created spawn templates re-open the stored path during spawn-time
revalidation. A relative path would be interpreted against the caller cwd
at spawn time, not necessarily the cwd used when the template was created.

Reject relative paths for now. Userspace can resolve the executable first
or create the template from an executable fd when it needs cwd-relative
lookup.

Signed-off-by: Li Chen <me@linux.beauty>
---
 Documentation/userspace-api/spawn_template.rst | 17 ++++++++++++++---
 fs/spawn_template.c                            |  2 ++
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/Documentation/userspace-api/spawn_template.rst b/Documentation/userspace-api/spawn_template.rst
index 0396d292fd17d..afe215e51db6f 100644
--- a/Documentation/userspace-api/spawn_template.rst
+++ b/Documentation/userspace-api/spawn_template.rst
@@ -30,9 +30,20 @@ returns a template fd.  The fd is an ordinary file descriptor backed by an
 anonymous inode.  Closing the fd releases the template.
 
 Userspace can identify the executable either by an existing executable fd or by
-path.  Exactly one of ``execfd`` and ``filename`` must be supplied.  Passing
-``SPAWN_TEMPLATE_CREATE_CLOEXEC`` sets ``O_CLOEXEC`` on the returned template
-fd.
+an absolute path.  Exactly one of ``execfd`` and ``filename`` must be supplied.
+Passing ``SPAWN_TEMPLATE_CREATE_CLOEXEC`` sets ``O_CLOEXEC`` on the returned
+template fd.
+
+Relative paths are rejected for path-created templates.  The kernel stores the
+filename and re-opens it at spawn time to check that the path still names the
+same executable.  A relative filename would be resolved against the caller's
+current working directory at spawn time, not the directory that was current
+when the template was created.  For example, a template created for ``bin/tool``
+while the caller is in ``/repo-a`` could later be spawned after the caller has
+changed to ``/repo-b``.  Revalidating ``bin/tool`` would then look under
+``/repo-b`` and give different semantics from the executable that was
+originally templated.  Userspace that wants directory-relative lookup should
+open the executable itself and create the template from ``execfd``.
 
 Creating a template for an unsupported executable format fails.  For this RFC
 that means non-ELF executables fail template creation rather than becoming a
diff --git a/fs/spawn_template.c b/fs/spawn_template.c
index a11a7ed676416..6430a6645fb57 100644
--- a/fs/spawn_template.c
+++ b/fs/spawn_template.c
@@ -441,6 +441,8 @@ static int spawn_template_open_filename(u64 filename, struct file **file,
 	tmp = strndup_user(u64_to_user_ptr(filename), PATH_MAX);
 	if (IS_ERR(tmp))
 		return PTR_ERR(tmp);
+	if (tmp[0] != '/')
+		return -EINVAL;
 	kfilename = tmp;
 
 	tmp_file = open_exec(kfilename);
-- 
2.52.0


  parent reply	other threads:[~2026-05-28  9:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28  9:52 [RFC PATCH v1 00/13] exec: add spawn templates for repeated executable startup Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 01/13] exec: factor argument setup out of do_execveat_common() Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 02/13] exec: add an internal helper for opened executables Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 03/13] file: expose helpers for in-kernel fd actions Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 04/13] exec: add spawn template UAPI definitions Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 05/13] exec: add spawn template file descriptors Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 06/13] exec: add spawn_template_spawn() Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 07/13] exec: validate spawn template executable identity Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 08/13] binfmt_elf: cache ELF metadata for spawn templates Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 09/13] Documentation: describe " Li Chen
2026-05-28  9:52 ` Li Chen [this message]
2026-05-28  9:52 ` [RFC PATCH v1 11/13] exec: let close-range actions target the max fd Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 12/13] syscalls: add generic spawn template entries Li Chen
2026-05-28  9:52 ` [RFC PATCH v1 13/13] selftests/exec: cover spawn template basics Li Chen
2026-05-28 11:02 ` [RFC PATCH v1 00/13] exec: add spawn templates for repeated executable startup Christian Brauner
2026-06-01  2:47   ` Li Chen
2026-06-01 19:55   ` Kees Cook
2026-05-28 12:55 ` Mateusz Guzik
2026-06-01 15:11   ` Li Chen
2026-05-28 18:27 ` Andy Lutomirski

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=20260528095235.2491226-11-me@linux.beauty \
    --to=me@linux.beauty \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=brauner@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jack@suse.cz \
    --cc=kees@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=skhan@linuxfoundation.org \
    --cc=tglx@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@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