git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/4] Add init-serve, the remote side of "git init --remote=host:path"
Date: Sat, 28 Feb 2009 22:16:09 -0500	[thread overview]
Message-ID: <20090301031609.GA30384@coredump.intra.peff.net> (raw)
In-Reply-To: <1235865822-14625-3-git-send-email-gitster@pobox.com>

On Sat, Feb 28, 2009 at 04:03:41PM -0800, Junio C Hamano wrote:

> +/*
> + * Notice any command line argument that we may not want to invoke
> + * "git init" with when we are doing this remotely, and reject the
> + * request.
> + */
> +static int forbidden_arg(const char *arg)
> +{
> +	if (!prefixcmp(arg, "--shared=") ||
> +	    !strcmp(arg, "--shared") ||
> +	    !strcmp(arg, "--bare"))
> +		return 0;
> +	return 1;
> +}

I started this mail to complain that this function was "disallow known
bad" instead of "allow known good". But then after reading it carefully
three times, I see that it is in fact "not allow known good". Can we
make it "allowed_arg" to prevent double negation?

> +		/*
> +		 * NEEDSWORK: I do not currently think it is worth it,
> +		 * but this might want to set up and use the sideband
> +		 * to capture and send output from the child back to
> +		 * the requestor.  At least this comment needs to be removed
> +		 * once we make the decision.
> +		 */
> +		child.stdout_to_stderr = 1;

I guess there is a potential information leak to say "directory does not
exist" versus "permission denied". Stopping such leaks often ends up
creating more harm (in confused users who don't know why it failed) than
good, but I think the fetch protocol is intentionally quiet here.

...

Actually, I just checked. Over ssh, you get:

  $ git fetch host:/nonexistent
  fatal: '/foo': unable to chdir or not a git archive
  fatal: The remote end hung up unexpectedly

But over git://, you get:

  $ git fetch git://host/nonexistent
  fatal: The remote end hung up unexpectedly

which I think is just because ssh relays stderr but the git daemon does
not.

So we are leaking the information to people authenticated via ssh (who
still might not be trusted or have full shell access, but are more
likely to be), but not to the whole world.

> +		/*
> +		 * NEEDSWORK: we might want to distinguish various
> +		 * error codes from run_command() and return different
> +		 * messages back.  I am too lazy to be bothered.
> +		 */
> +		if (run_command(&child))
> +			errmsg = "bad";

I think this somewhat falls into the same category as above (though
perhaps the information is less interesting).

-Peff

  parent reply	other threads:[~2009-03-01  3:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-01  0:03 [PATCH 1/4] Refactor list of environment variables to be sanitized Junio C Hamano
2009-03-01  0:03 ` [PATCH 2/4] git-init: inject some sanity to the option parser Junio C Hamano
2009-03-01  0:03   ` [PATCH 3/4] Add init-serve, the remote side of "git init --remote=host:path" Junio C Hamano
2009-03-01  0:03     ` [PATCH 4/4] " Junio C Hamano
2009-03-01  3:16     ` Jeff King [this message]
2009-03-01  5:54       ` [PATCH 3/4] Add init-serve, the remote side of " Junio C Hamano
2009-03-01 10:00         ` Jeff King
2009-03-01 17:04           ` Shawn O. Pearce
2009-03-03  6:50             ` Subject: [PATCH] Push to create Junio C Hamano
2009-03-03  7:09               ` Jay Soffian
2009-03-03  7:09               ` Jeff King
2009-03-03  7:37                 ` Jay Soffian
2009-03-03  7:39                   ` Jay Soffian
2009-03-03  7:56                   ` Junio C Hamano
2009-03-03  8:02                     ` Jay Soffian
2009-03-03  8:04                       ` Junio C Hamano
2009-03-03  8:04                       ` Junio C Hamano
2009-03-03  8:16                         ` Jay Soffian
2009-03-03  8:23                     ` Jeff King
2009-03-03 19:57                       ` Jay Soffian
2009-03-04  5:42                         ` Jeff King
2009-03-04  6:35                           ` Junio C Hamano
2009-03-04 13:06                           ` Jay Soffian
2009-03-03  7:55                 ` Junio C Hamano
2009-03-03  8:06                   ` Jeff King
2009-03-03  8:22                     ` Junio C Hamano
2009-03-03  8:27                       ` Jeff King
2009-03-03  8:30                         ` Junio C Hamano
2009-03-03  8:41                           ` Jay Soffian
2009-03-03  9:23                           ` Theodore Tso
2009-03-03 10:39                             ` Johannes Schindelin
2009-03-04 17:58                               ` Theodore Tso
2009-03-06  1:37                                 ` Miles Bader
2009-03-03 18:41                             ` Shawn O. Pearce
2009-03-04  8:32                               ` [RFC/PATCH 1/2] improve missing repository error message Jeff King
2009-03-04  9:19                                 ` Matthieu Moy
2009-03-04 10:35                                   ` Jeff King
2009-03-04 18:57                                 ` Shawn O. Pearce
2009-03-05 10:36                                   ` Jeff King
2009-03-04  8:42                               ` [RFC/PATCH 2/2] make remote hangup warnings more friendly Jeff King
2009-03-04 19:04                                 ` Shawn O. Pearce
2009-03-05 10:45                                   ` Jeff King
2009-03-03 21:08                   ` Subject: [PATCH] Push to create Daniel Barkalow

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=20090301031609.GA30384@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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;
as well as URLs for NNTP newsgroup(s).