git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 2/2] run-command: mark path lookup errors with ENOENT
Date: Wed, 24 Oct 2018 11:01:54 +0200 (DST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1810241054110.4546@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20181024073800.GB31202@sigill.intra.peff.net>

Hi Peff,

On Wed, 24 Oct 2018, Jeff King wrote:

> Since commit e3a434468f (run-command: use the
> async-signal-safe execv instead of execvp, 2017-04-19),
> prepare_cmd() does its own PATH lookup for any commands we
> run (on non-Windows platforms).
> 
> However, its logic does not match the old execvp call when
> we fail to find a matching entry in the PATH. Instead of
> feeding the name directly to execv, execvp would consider
> that an ENOENT error. By continuing and passing the name
> directly to execv, we effectively behave as if "." was
> included at the end of the PATH. This can have confusing and
> even dangerous results.

For the record, I tried to come up with an attack vector to exploit this,
and failed to find one.

> The fix itself is pretty straight-forward. There's a new
> test in t0061 to cover this explicitly, and I've also added
> a duplicate of the ENOENT test to ensure that we return the
> correct errno for this case.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  run-command.c          | 20 ++++++++++++++++----
>  t/t0061-run-command.sh | 13 ++++++++++++-
>  2 files changed, 28 insertions(+), 5 deletions(-)
> 
> diff --git a/run-command.c b/run-command.c
> index 84b883c213..639ea5ac33 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -380,7 +380,7 @@ static void child_err_spew(struct child_process *cmd, struct child_err *cerr)
>  	set_error_routine(old_errfn);
>  }
>  
> -static void prepare_cmd(struct argv_array *out, const struct child_process *cmd)
> +static int prepare_cmd(struct argv_array *out, const struct child_process *cmd)

I always like when we change functions to return a value that can then
indicate an error, making the libification effort so much easier.

>  {
>  	if (!cmd->argv[0])
>  		BUG("command is empty");
> @@ -403,16 +403,22 @@ static void prepare_cmd(struct argv_array *out, const struct child_process *cmd)
>  	/*
>  	 * If there are no '/' characters in the command then perform a path
>  	 * lookup and use the resolved path as the command to exec.  If there
> -	 * are no '/' characters or if the command wasn't found in the path,
> -	 * have exec attempt to invoke the command directly.
> +	 * are '/' characters, we have exec attempt to invoke the command
> +	 * directly.

Nice. I would have probably forgotten about that comment.

>  	 */
>  	if (!strchr(out->argv[1], '/')) {
>  		char *program = locate_in_PATH(out->argv[1]);
>  		if (program) {
>  			free((char *)out->argv[1]);
>  			out->argv[1] = program;
> +		} else {
> +			argv_array_clear(out);
> +			errno = ENOENT;
> +			return -1;
>  		}
>  	}
> +
> +	return 0;
>  }
>  
>  static char **prep_childenv(const char *const *deltaenv)
> @@ -719,6 +725,12 @@ int start_command(struct child_process *cmd)
>  	struct child_err cerr;
>  	struct atfork_state as;
>  
> +	if (prepare_cmd(&argv, cmd) < 0) {
> +		failed_errno = errno;
> +		cmd->pid = -1;
> +		goto end_of_spawn;
> +	}
> +
>  	if (pipe(notify_pipe))
>  		notify_pipe[0] = notify_pipe[1] = -1;
>  
> @@ -729,7 +741,6 @@ int start_command(struct child_process *cmd)
>  		set_cloexec(null_fd);
>  	}
>  
> -	prepare_cmd(&argv, cmd);
>  	childenv = prep_childenv(cmd->env);
>  	atfork_prepare(&as);
>  
> @@ -910,6 +921,7 @@ int start_command(struct child_process *cmd)
>  }
>  #endif
>  
> +end_of_spawn:

Sadly, this fails to build on Windows:

	run-command.c: In function 'start_command':
	run-command.c:924:1: error: label 'end_of_spawn' defined but not used [-Werror=unused-label]
	 end_of_spawn:
	 ^~~~~~~~~~~~

How about squashing in this diff:

-- snip --
diff --git a/run-command.c b/run-command.c
index 639ea5ac3366..3f03795a5995 100644
--- a/run-command.c
+++ b/run-command.c
@@ -918,6 +918,8 @@ int start_command(struct child_process *cmd)
 		close(fhout);
 	if (fherr != 2)
 		close(fherr);
+
+	goto end_of_spawn;
 }
 #endif
 
-- snap --

I can confirm that the result compiles and passes t0061.

Thanks,
Dscho

>  	if (cmd->pid < 0) {
>  		if (need_in)
>  			close_pair(fdin);
> diff --git a/t/t0061-run-command.sh b/t/t0061-run-command.sh
> index 3e131c5325..cf932c8514 100755
> --- a/t/t0061-run-command.sh
> +++ b/t/t0061-run-command.sh
> @@ -12,10 +12,14 @@ cat >hello-script <<-EOF
>  	cat hello-script
>  EOF
>  
> -test_expect_success 'start_command reports ENOENT' '
> +test_expect_success 'start_command reports ENOENT (slash)' '
>  	test-tool run-command start-command-ENOENT ./does-not-exist
>  '
>  
> +test_expect_success 'start_command reports ENOENT (no slash)' '
> +	test-tool run-command start-command-ENOENT does-not-exist
> +'
> +
>  test_expect_success 'run_command can run a command' '
>  	cat hello-script >hello.sh &&
>  	chmod +x hello.sh &&
> @@ -25,6 +29,13 @@ test_expect_success 'run_command can run a command' '
>  	test_must_be_empty err
>  '
>  
> +test_expect_success 'run_command is restricted to PATH' '
> +	write_script should-not-run <<-\EOF &&
> +	echo yikes
> +	EOF
> +	test_must_fail test-tool run-command run-command should-not-run
> +'
> +
>  test_expect_success !MINGW 'run_command can run a script without a #! line' '
>  	cat >hello <<-\EOF &&
>  	cat hello-script
> -- 
> 2.19.1.1094.gd480080bf6
> 

  reply	other threads:[~2018-10-24  9:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-24  7:36 [PATCH 0/2] run-command: fix Unix PATH lookup Jeff King
2018-10-24  7:37 ` [PATCH 1/2] t5410: use longer path for sample script Jeff King
2018-10-24  8:53   ` Johannes Schindelin
2018-10-25  1:15     ` Junio C Hamano
2018-10-24  7:38 ` [PATCH 2/2] run-command: mark path lookup errors with ENOENT Jeff King
2018-10-24  9:01   ` Johannes Schindelin [this message]
2018-10-24  9:16     ` Jeff King
2018-10-24  9:25       ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1810241054110.4546@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).