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

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

[Johan Sørensen]

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

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

[Shawn O. Pearce]

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.

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

[Johan Sørensen]

On Wed, Jun 24, 2009 at 3:57 PM, Shawn O. Pearce<spearce@spearce.org> wrote:
> 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

>> 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