[PATCH] posix: execvpe: skip $PATH components that are too long

[Adhemerval Zanella Netto]

On 18/11/25 10:27, Pádraig Brady wrote:
> Bruno Haible wrote:
>> Paul Eggert wrote:
>> > The situation for ENAMETOOLONG is the same.
>>
>> Well, in [1] I'm arguing that the situation for ENAMETOOLONG is
>> _not_ the same. If one ignores ENAMETOOLONG errors from earlier PATH
>> elements, a user's intent to hide (override) a certain program from
>> later PATH elements is no longer honored.
> 
>> One could consider this as security relevant. CCing Florian.
> 
> In summary I don't think we should be treating ENAMETOOLONG
> differently to how we treat EACCES or ENOTDIR.
> If we can't access file through a path, then we should try the next one.
> 
> There are a few cases to consider:
> 
> 1. /many/path/file > PATH_MAX
> 2. /path/longpath/file > NAME_MAX
> 3. /path/longfile > NAME_MAX
> 
> 3. is already handled by glibc's execvpe, so let's just consider 1. and 2.
> 
> It's also worth noting that these limits can vary based on the file system.
> For example we've seen NAME_MAX = 143 on ecryptfs as it uses some of the
> file name space for encrypting file names.
> 
> With 2. the path can't exist on the (file) system,
> so you'd want to treat that like ENOTDIR IMHO.
> 
> With 1. the /many/path/file might exist, but since it's not accessible
> you'd want to treat that like EACCES IMHO.
> This case is also more of an edge case I think.
> 
> The use case of a user wanting ENAMETOOLONG to abort $PATH processing would be unusual.
> If they have access to changing $PATH then the natural way to achieve that functionality
> would be to remove entries they want avoided.
> 
> Given the fairly constrained NAME_MAX in some cases (like on ecryptfs),
> I think it's more expected to continue processing paths
> when encountering ENAMETOOLONG.
> 

I think it makes sense to handle ENAMETOOLONG as ENOENT, ESTALE, ENOTDIR,
ENODEV, and ETIMEDOUT.  It is consistency with the systems (BSDs) and how
other executors already handle it (shells).


> From 5cba04e01912a76765abeae1156d4c0d9285af73 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?P=C3=A1draig=20Brady?= <P@draigBrady.com>
> Date: Sat, 8 Nov 2025 15:44:08 +0000
> Subject: [PATCH] posix: execvpe: skip $PATH components that are too long [BZ
>  #33626]
> 
> * posix/execvpe.c (__execvpe_common): Rather than error out
> with ENAMETOOLONG, just ignore and try the next path.
> Note we know the FILE length is <= NAME_MAX, so the ENAMETOOLONG
> almost certainly pertains to the current $PATH entry.
> * posix/tst-execvpe7.c: A new test based on tst-execvp3.c.
> * posix/Makefile: Reference the new test.
> ---
>  posix/Makefile       |  1 +
>  posix/execvpe.c      |  3 +++
>  posix/tst-execvpe7.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 65 insertions(+)
>  create mode 100644 posix/tst-execvpe7.c
> 
> diff --git a/posix/Makefile b/posix/Makefile
> index f6421e5379..3797c46872 100644
> --- a/posix/Makefile
> +++ b/posix/Makefile
> @@ -277,6 +277,7 @@ tests := \
>    tst-execvpe4 \
>    tst-execvpe5 \
>    tst-execvpe6 \
> +  tst-execvpe7 \
>    tst-fexecve \
>    tst-fnmatch \
>    tst-fnmatch2 \
> diff --git a/posix/execvpe.c b/posix/execvpe.c
> index c139dfe8fd..0fb09b9631 100644
> --- a/posix/execvpe.c
> +++ b/posix/execvpe.c
> @@ -156,6 +156,9 @@ __execvpe_common (const char *file, char *const argv[], char *const envp[],
>  	  /* Those errors indicate the file is missing or not executable
>  	     by us, in which case we want to just try the next path
>  	     directory.  */
> +	  case ENAMETOOLONG:
> +	  /* We've already verified that the FILE length is < NAME_MAX,
> +	     so this implies a path component is too long, so skip it.  */
>  	  case ENODEV:
>  	  case ETIMEDOUT:
>  	  /* Some strange filesystems like AFS return even
> diff --git a/posix/tst-execvpe7.c b/posix/tst-execvpe7.c
> new file mode 100644
> index 0000000000..36ca0903fd
> --- /dev/null
> +++ b/posix/tst-execvpe7.c
> @@ -0,0 +1,61 @@
> +/* Check execvpe script argument handling.
> +   Copyright (C) 2016-2025 Free Software Foundation, Inc.
> +   This file is part of the GNU C Library.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, see
> +   <https://www.gnu.org/licenses/>.  */
> +
> +#include <limits.h>
> +#include <support/xstdio.h>
> +#include <support/test-driver.h>
> +#include <support/support.h>
> +#include <support/temp_file.h>
> +#include <support/check.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <sys/param.h>
> +#include <sys/stat.h>
> +
> +static char *fname;
> +
> +static void
> +do_prepare (int c, char** argv)
> +{
> +  int fd;
> +  TEST_VERIFY_EXIT (( fd = create_temp_file ("testscript", &fname)) != -1);
> +  dprintf (fd, "echo foo\n");
> +  TEST_VERIFY_EXIT (fchmod (fd, 0700) == 0);
> +  TEST_VERIFY_EXIT (close (fd) == 0);
> +}
> +#define PREPARE do_prepare
> +
> +static int
> +do_test (void)
> +{
> +  /* Linux 6.17 at least will give ENAMETOOLONG once any
> +     path component is > NAME_MAX, so ensure we skip such paths
> +     rather than failing.  [BZ #33626] */
> +  char *path = xasprintf ("%*s:%s", NAME_MAX+1, "", test_dir);
> +  TEST_VERIFY_EXIT (setenv ("PATH", path, 1) == 0);
> +  free (path);
> +
> +  char *argv[] = { fname, NULL };
> +  execvpe (basename (fname), argv, NULL);
> +
> +  /* If we come here, the execvpe call failed.  */
> +  return 1;
> +}
> +
> +#include <support/test-driver.c>

I think we also need to check if the output of the command execution
does match what we expect ("foo\n"). Something like:

--

#include <stdlib.h>
#include <libgen.h>
#include <limits.h>

#include <support/capture_subprocess.h>
#include <support/check.h>
#include <support/support.h>
#include <support/temp_file.h>
#include <support/test-driver.h>
#include <support/xunistd.h>

static char *fname;

static void
do_prepare (int c, char** argv)
{
  int fd;
  TEST_VERIFY_EXIT ((fd = create_temp_file ("testscript", &fname)) != -1);

  dprintf (fd, "echo foo\n");
  TEST_VERIFY_EXIT (fchmod (fd, 0700) == 0);
  xclose (fd);
}
#define PREPARE do_prepare

static void
run_execvpe (void *closure)
{
  char *argv[] = { fname, NULL };
  execvpe (basename (fname), argv, NULL);

  support_record_failure ();
}

static int
do_test (void)
{
  /* Linux 6.17 at least will give ENAMETOOLONG once any
     path component is > NAME_MAX, so ensure we skip such paths
     rather than failing.  [BZ #33626] */
  char *path = xasprintf ("%*s:%s", NAME_MAX+1, "", test_dir);
  TEST_VERIFY_EXIT (setenv ("PATH", path, 1) == 0);
  free (path);

  struct support_capture_subprocess result
    = support_capture_subprocess (run_execvpe, NULL);
  support_capture_subprocess_check (&result, "execvpe", 0, sc_allow_stdout);

  TEST_COMPARE_STRING (result.out.buffer, "foo\n");

  support_capture_subprocess_free (&result);

  return 0;
}

#include <support/test-driver.c>