git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Erik E Brady <brady@cisco.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] credential: cred helper fast exit can cause SIGPIPE, crash
Date: Thu, 29 Mar 2018 07:19:15 -0400	[thread overview]
Message-ID: <20180329111915.GA30797@sigill.intra.peff.net> (raw)
In-Reply-To: <20180328222051.23684-1-brady@cisco.com>

On Wed, Mar 28, 2018 at 03:20:51PM -0700, Erik E Brady wrote:

> Subject: Re: [PATCH] credential: cred helper fast exit can cause SIGPIPE, crash

Thanks for sending this. The patch itself looks good to me, but I have a
few nits with your commit message.

We usually write commit messages in the imperative, with the subject
summarizing the change. So:

  Subject: credential: ignore SIGPIPE when writing to credential helpers

or similar.

> credential.c, run_credential_helper(): now ignores SIGPIPE
> when writing to credential helper.  Avoids problem with race
> where cred helper exits very quickly and, after, git tries
> to write to it, generating SIGPIPE and crashing git.  To
> reproduce this the cred helper must not read from STDIN.

We can stop being terse outside of the subject line. :) I'd probably
write something like:

  The credential subsystem can trigger SIGPIPE when writing to an
  external helper if that helper closes its stdin before reading the
  whole input. Normally this is rare, since helpers would need to read
  that input to make a decision about how to respond, but:

    1. It's reasonable to configure a helper which blindly a "get"
       answer, and trigger it only for certain hosts via config like:

         [credential "https://example.com"]
	 helper = "!get-example-password"

    2. A broken or misbehaving helper might exit immediately. That's an
       error, but it's not reasonable for it to take down the parent Git
       process with SIGPIPE.

  Even with such a helper, seeing this problem should be rare. Getting
  SIGPIPE requires the helper racily exiting before we've written the
  fairly small credential output.

Feel free to steal or adapt any of that as you see fit.

> This was seen with a custom credential helper, written in
> Go, which ignored the store command (STDIN not read) and
> then did a quick exit.  Even with this fast helper the race
> was pretty rare, ie: was only seen on some of our older VM's
> running 2.6.18-416.el5 #1 SMP linux for whatever reason.  On
> these VM's it occurred only once every few hundred git cmds.
> ---

Missing signoff. See Documentation/SubmittingPatches, especially the
'sign-off' and 'dco' sections.

>  credential.c | 3 +++
>  1 file changed, 3 insertions(+)

No test, but I think that's fine here. Any such test would be inherently
racy.

> @@ -227,8 +228,10 @@ static int run_credential_helper(struct credential *c,
>  		return -1;
>  
>  	fp = xfdopen(helper.in, "w");
> +	sigchain_push(SIGPIPE, SIG_IGN);
>  	credential_write(c, fp);
>  	fclose(fp);
> +	sigchain_pop(SIGPIPE);

This looks like the right place to put the push/pop (as you noted
before, we may not write until fclose flushes, so it definitely has to
go after that).

Thanks again for digging this up. It's pretty subtle. :)

-Peff

  reply	other threads:[~2018-03-29 11:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 22:20 [PATCH] credential: cred helper fast exit can cause SIGPIPE, crash Erik E Brady
2018-03-29 11:19 ` Jeff King [this message]
2018-03-29 17:25   ` Erik Brady -X (brady - ROBERT HALF INTERNATIONAL INC at Cisco)
2018-03-29 17:55     ` Jeff King
2018-03-29 18:00       ` [PATCH] credential: ignore SIGPIPE when writing to credential helpers Erik E Brady
2018-03-29 21:51         ` Jeff King
2018-03-29 22:20           ` Erik Brady -X (brady - ROBERT HALF INTERNATIONAL INC at Cisco)
2018-03-29 22:29             ` Jeff King
2018-03-29 22:35           ` Junio C Hamano

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=20180329111915.GA30797@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=brady@cisco.com \
    --cc=git@vger.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.
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).