Re: what are the chances of a 'pre-upload' hook?

[Jeff King <peff@peff.net>]

On Mon, Nov 28, 2011 at 01:47:44PM +0530, Sitaram Chamarty wrote:

> > Jeff may be right that any approach based on hooks cannot be made totally
> > safe. But the discussion can lead to a workable alternative. The "enable
> > the hook only on git:// and http:// and no other" approach might or might
> > not be such a workable alternative. The "try talking to a service process
> > via named pipe, instead of spawning a hook" might or might not be such a
> > workable alternative. Other possibilities may be there to be explored.
> 
> There are only 2 cases: git-upload-pack runs as invoking user, or it
> runs as some common user/repo owner.

I think it is slightly more complicated. You may have a common user, but
that user may or may not trust the contents of the repo on disk (e.g.,
a system daemon serving repos for arbitrary users).

> I see pre-upload hooks for case 1 as being hard/impossible to do,
> while case 2 is trivial (just check if the hook file owner == UID of
> the git-upload-pack process).

The UID check doesn't quite tell you what you want. If I am in a shared
repo situation with a liberal umask and I write a hook, it will have my
UID. But it may have group-write permissions. Other people in my group
can write arbitrary contents to the file, but it will retain my UID, and
git's check will think the code is OK to run.

> Yes, this means pre-upload won't work identically in *all* setups.
> But as you said somewhere: perfect is the enemy of good.

Yes, I think we have to accept inconsistency if we have them at all.
Because such hooks are dangerous in some setups, and OK in others. So no
matter what the rule for determining danger, they will sometimes run and
sometimes not.

-Peff