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
>
next prev parent 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).