git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Robin H. Johnson" <robbat2@gentoo.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Removal of post-upload-hook
Date: Fri, 15 Jan 2010 09:47:36 -0500	[thread overview]
Message-ID: <20100115144736.GC621@coredump.intra.peff.net> (raw)
In-Reply-To: <20100114210645.GE16921@orbis-terrarum.net>

On Thu, Jan 14, 2010 at 09:06:45PM +0000, Robin H. Johnson wrote:

> As a reasonable middle ground between the functionality and complete
> removal, can we find a way just to only execute the potentially
> dangerous hooks under known safe conditions or when explicitly requested
> by the user.

An alternative to ripping it out that was discussed is to check that
getuid() matches the owner of the hook.

That might be a nice improvement in security for the push hooks, as
well. But it does come at the cost of some inconvenience. How do you set
up hooks in a shared central repo that every user should trigger? You
need some way to say "these hooks really _are_ trusted, run them
anyway", but that mechanism cannot be in the configuration of the repo
itself for obvious reasons. I suppose if the owner is root? But that
leaves no way for non-root users to set up shared access.

Also, there is a similar issue with config. Right now, if I can convince
you to run "git log" in a repo whose config I own, I can make you run
arbitrary commands via textconv (and ditto for "git diff" and external
diff).

> Places where the hooks are safe:
> - the hooks are known trusted AND not writable by the user/group.
>   (e.g. "chown -R root:root hooks/").

This can work, but has drawbacks. See above.

> - Systems where the users/groups do not have full shell access, just
>   access to run Git itself. Eg gitosis, regular git+ssh:// w/ a
>   restricted shell.

Yes, this would work, too, but how do you configure the "it's OK to run
random hooks" flag? Environment?

-Peff

  reply	other threads:[~2010-01-15 14:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-14 18:01 Removal of post-upload-hook Arun Raghavan
2010-01-14 19:36 ` Jeff King
2010-01-14 19:41   ` Shawn O. Pearce
2010-01-14 19:52     ` Arun Raghavan
2010-01-14 20:43     ` Jeff King
2010-01-14 21:06       ` Robin H. Johnson
2010-01-15 14:47         ` Jeff King [this message]
2010-01-15  6:12       ` Arun Raghavan
2010-01-15 11:52         ` Ilari Liusvaara
2010-01-15 12:14           ` Arun Raghavan
2010-02-01  8:32             ` [PATCH 0/2] upload-pack: pre- and post- hooks Arun Raghavan
2010-02-01  8:32               ` [PATCH 1/2] upload-pack: Reinstate the post-upload-pack hook Arun Raghavan
2010-02-01  8:32                 ` [PATCH 2/2] upload-pack: Add a pre-upload-pack hook Arun Raghavan
2010-02-01 15:20               ` [PATCH 0/2] upload-pack: pre- and post- hooks Shawn O. Pearce
2010-02-01 15:50                 ` Arun Raghavan
2010-02-01 16:01                   ` Shawn O. Pearce
2010-02-02  5:50                     ` Arun Raghavan
2010-02-01 16:30                 ` Nicolas Pitre
2010-02-01 16:36                   ` Shawn O. Pearce
2010-02-02  5:52                     ` Arun Raghavan
2010-02-02  6:15                       ` Nicolas Pitre

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=20100115144736.GC621@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=robbat2@gentoo.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.
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).