threads / discuss / 19916

Reason for objects still being written with a failing pre-receive hook?

Subject: Reason for objects still being written with a failing pre-receive hook?

## tl;dr

3 messages between Jun 24, 2009 and Jun 24, 2009.

replies: 2people: 2as markdown or json

Johan Sørensen· Jun 24, 2009, 13:21 UTC · lore

Hi,

I'm wondering what the reason is that objects are still being stored, despite a non-zero exit code from the pre-receive hook?

Obviously refs aren't being updated, but I can see this a gateway for abuse if I want to control push permissions per ref via the pre-receive hook (which is the earliest place I know about the ref being pushed to, unless I've missed something). Basically an abuser could continuously attempt to push a set of commits with large blobs to a repo the pre-receive hook doesn't give him access to, and eventually fill up the repo with useless objects. I could nuke these with git-prune (after the fact though), but still it seems illogical that one is allowed to even write the objects in the first place if the hook fails.

If it's expected and accepted behaviour, what other options do I have to prevent a scenario like the above?

Cheers, Johan

Shawn O. Pearce· Jun 24, 2009, 13:57 UTC · re: Johan Sørensen · lore

Re: Reason for objects still being written with a failing pre-receive hook?

Johan S?rensen <johan@johansorensen.com> wrote:

> I'm wondering what the reason is that objects are still being stored,
> despite a non-zero exit code from the pre-receive hook?

The pre-receive hook is allowed to inspect the objects that have
been uploaded in order to make its access decision.  Thus those
objects must have been unpacked (or indexed into a new pack) so
git commands in the pre-receive hook can read them.

> If it's expected and accepted behaviour, what other options do I have
> to prevent a scenario like the above?

There currently isn't a way to stop this, other than to use something in front of git-receive-pack, e.g. Gitosis, to deny even forking the receive-pack binary for the user.

-- 
Shawn.

Johan Sørensen· Jun 24, 2009, 14:36 UTC · re: Shawn O. Pearce · lore

Re: Reason for objects still being written with a failing pre-receive hook?

On Wed, Jun 24, 2009 at 3:57 PM, Shawn O. Pearce<spearce@spearce.org> wrote:

Show 8 quoted lines

> Johan S?rensen <johan@johansorensen.com> wrote:
>> I'm wondering what the reason is that objects are still being stored,
>> despite a non-zero exit code from the pre-receive hook?
>
> The pre-receive hook is allowed to inspect the objects that have
> been uploaded in order to make its access decision.  Thus those
> objects must have been unpacked (or indexed into a new pack) so
> git commands in the pre-receive hook can read them.

Yeah, noticed that after I started digging into the code a bit

Show 6 quoted lines

>> If it's expected and accepted behaviour, what other options do I have
>> to prevent a scenario like the above?
>
> There currently isn't a way to stop this, other than to use something
> in front of git-receive-pack, e.g. Gitosis, to deny even forking
> the receive-pack binary for the user.

Well, I already wrote such a thing (Gitorious.org) but I want to take the auth a little bit further and offer some more fine-grained access-controls and discovered the above during some smoke testing.

>
> --
> Shawn.

Thanks JS