{"thread":{"id":"19916","subject":"Reason for objects still being written with a failing pre-receive hook?","startedAt":"2009-06-24T13:21:09Z","lastAt":"2009-06-24T14:36:38Z","messageCount":3,"participants":["Johan Sørensen","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"116862","messageId":"9e0f31700906240621k314b4bbehc283c8a1c673a2f1@mail.gmail.com","threadId":"19916","inReplyTo":null,"subject":"Reason for objects still being written with a failing pre-receive hook?","fromName":"Johan Sørensen","fromEmail":"johan@johansorensen.com","sentAt":"2009-06-24T13:21:09Z","receivedAt":"2009-06-24T13:21:09Z","isPatch":false,"sender":{"key":"johan@johansorensen.com","avatar":"https://gravatar.com/avatar/dad7869db9d9711098ad213108d1b09967181bb51b667d5a5088c7634ce46616?d=mp&s=160"},"body":"Hi,\n\nI'm wondering what the reason is that objects are still being stored,\ndespite a non-zero exit code from the pre-receive hook?\n\nObviously refs aren't being updated, but I can see this a gateway for\nabuse if I want to control push permissions per ref via the\npre-receive hook (which is the earliest place I know about the ref\nbeing pushed to, unless I've missed something). Basically an abuser\ncould continuously attempt to push a set of commits with large blobs\nto a repo the pre-receive hook doesn't give him access to, and\neventually fill up the repo with useless objects. I could nuke these\nwith git-prune (after the fact though), but still it seems illogical\nthat one is allowed to even write the objects in the first place if\nthe hook fails.\n\nIf it's expected and accepted behaviour, what other options do I have\nto prevent a scenario like the above?\n\nCheers,\nJohan\n"},{"id":"116864","messageId":"20090624135713.GE11191@spearce.org","threadId":"19916","inReplyTo":"9e0f31700906240621k314b4bbehc283c8a1c673a2f1@mail.gmail.com","subject":"Re: Reason for objects still being written with a failing pre-receive hook?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-06-24T13:57:13Z","receivedAt":"2009-06-24T13:57:13Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johan S?rensen <johan@johansorensen.com> wrote:\n> I'm wondering what the reason is that objects are still being stored,\n> despite a non-zero exit code from the pre-receive hook?\n\nThe pre-receive hook is allowed to inspect the objects that have\nbeen uploaded in order to make its access decision.  Thus those\nobjects must have been unpacked (or indexed into a new pack) so\ngit commands in the pre-receive hook can read them.\n \n> If it's expected and accepted behaviour, what other options do I have\n> to prevent a scenario like the above?\n\nThere currently isn't a way to stop this, other than to use something\nin front of git-receive-pack, e.g. Gitosis, to deny even forking\nthe receive-pack binary for the user.\n\n-- \nShawn.\n"},{"id":"116865","messageId":"9e0f31700906240736r50d2de51kc50822619ec619fa@mail.gmail.com","threadId":"19916","inReplyTo":"20090624135713.GE11191@spearce.org","subject":"Re: Reason for objects still being written with a failing pre-receive hook?","fromName":"Johan Sørensen","fromEmail":"johan@johansorensen.com","sentAt":"2009-06-24T14:36:38Z","receivedAt":"2009-06-24T14:36:38Z","isPatch":false,"sender":{"key":"johan@johansorensen.com","avatar":"https://gravatar.com/avatar/dad7869db9d9711098ad213108d1b09967181bb51b667d5a5088c7634ce46616?d=mp&s=160"},"body":"On Wed, Jun 24, 2009 at 3:57 PM, Shawn O. Pearce<spearce@spearce.org> wrote:\n> Johan S?rensen <johan@johansorensen.com> wrote:\n>> I'm wondering what the reason is that objects are still being stored,\n>> despite a non-zero exit code from the pre-receive hook?\n>\n> The pre-receive hook is allowed to inspect the objects that have\n> been uploaded in order to make its access decision.  Thus those\n> objects must have been unpacked (or indexed into a new pack) so\n> git commands in the pre-receive hook can read them.\n\nYeah, noticed that after I started digging into the code a bit\n\n>> If it's expected and accepted behaviour, what other options do I have\n>> to prevent a scenario like the above?\n>\n> There currently isn't a way to stop this, other than to use something\n> in front of git-receive-pack, e.g. Gitosis, to deny even forking\n> the receive-pack binary for the user.\n\nWell, I already wrote such a thing (Gitorious.org) but I want to take\nthe auth a little bit further and offer some more fine-grained\naccess-controls and discovered the above during some smoke testing.\n\n>\n> --\n> Shawn.\n\nThanks\nJS\n"}]}