git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Magnus Therning <magnus@therning.org>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: git-http-backend: anonymous read, authenticated write
Date: Wed, 10 Apr 2013 22:45:44 +0200	[thread overview]
Message-ID: <20130410204544.GA2472@mteis.lan> (raw)
In-Reply-To: <20130409171247.GD21972@sigill.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 5523 bytes --]

On Tue, Apr 09, 2013 at 01:12:47PM -0400, Jeff King wrote:
> On Tue, Apr 09, 2013 at 07:45:53AM +0200, Magnus Therning wrote:
> 
>> I've been trying to set up git-http-backend+lighttpd.  I've managed
>> to set up anonymous read-only access, and I then successfully
>> configured authentication for both read and write.  Then I get
>> stuck.  The man-page for git-http-backend says that the following
>> snippet can be used for Apache 2.x:
>> 
>>     <LocationMatch "^/git/.*/git-receive-pack$">
>>         AuthType Basic
>>         AuthName "Git Access"
>>         Require group committers
>>         ...
>>     </LocationMatch>
>> 
>> However, when I put in this match on location in my lighty config
>> and try to push I'm not asked for a password, instead I'm greeted
>> with
>> 
>>     % git push 
>>     error: The requested URL returned error: 403 Forbidden while accessing http://magnus@tracsrv.local/git/foo.git/info/refs?service=git-receive-pack
> 
> Something in your config is blocking access to info/refs there. It
> should not be the block shown above, which handles only the actual POST
> of the data. The sequence of http requests made is:
> 
>   1. GET $repo/info/refs?service=git-receive-pack
> 
>      This makes initial contact and gets the ref information which push
>      uses to decide what it is going to push. So it is read-only, and in
>      an anonymous-read setup, does not need to be protected.
> 
>   2. POST $repo/git-receive-pack
> 
>      This actually pushes up the objects and updates the refs, and
>      must be protected.
> 
> The setup listed above does work with apache; it is tested as part of
> our test suite (you can see the actual config in t/lib-httpd/apache.conf).
> So what in lighttpd is giving us the 403? Can you share your whole
> config?

I was putting together a *long* response, with my different
configurations when it suddenly hit me how to make it work.

So, this is the accesslog for a successful `git push`:

192.168.1.84 tracsrv.local - [10/Apr/2013:22:24:59 +0200] "GET /git/foo.git/info/refs?service=git-receive-pack HTTP/1.1" 401 351 "-" "git/1.8.2.1"
192.168.1.84 tracsrv.local - [10/Apr/2013:22:24:59 +0200] "GET /git/foo.git/info/refs?service=git-receive-pack HTTP/1.1" 401 351 "-" "git/1.8.2.1"
192.168.1.84 tracsrv.local magnus [10/Apr/2013:22:25:04 +0200] "GET /git/foo.git/info/refs?service=git-receive-pack HTTP/1.1" 200 202 "-" "git/1.8.2.1"
192.168.1.84 tracsrv.local magnus [10/Apr/2013:22:25:09 +0200] "POST /git/foo.git/git-receive-pack HTTP/1.1" 200 73 "-" "git/1.8.2.1"

That is, *both* the GET and POST queries require a valid username
(trying to push without a valid user will fail with a 403 already on
the GET query).  Maybe Apache 2.x simply behaves *very* differently
from lighttpd, but I still can't see how a rule to require a valid
user only on the POST can ever work.

>> AFAICS this means the man-page is wrong, and that I instead ought
>> to match on the "service=git-receive-pack" part.  Is that a correct
>> conclusion?
> 
> No. It is not a bad idea to _also_ match on info/refs, but I think
> it's a little trickier (you need to reliably match the query string
> to differentiate it from a fetch, which IIRC is a little hard in
> apache, at least).

This is what triggered me to find a working config.  Matching on the
query string is actually *very* easy in lighttpd.  Here's the relevant
bit of a working configuration[1]:

    alias.url += ( "/git" => "/usr/lib/git-core/git-http-backend" )
    $HTTP["querystring"] =~ "service=git-receive-pack" {
        $HTTP["url"] =~ "^/git" {
            cgi.assign = ( "" => "" )
            setenv.add-environment = (
                "GIT_PROJECT_ROOT" => "/srv/git",
                "GIT_HTTP_EXPORT_ALL" => ""
            )
            include "trac-git-auth.conf"
        }
    } else $HTTP["url"] =~ "^/git/.*/git-receive-pack$" {
        cgi.assign = ( "" => "" )
        setenv.add-environment = (
            "GIT_PROJECT_ROOT" => "/srv/git",
            "GIT_HTTP_EXPORT_ALL" => ""
        )
        include "trac-git-auth.conf"
    } else $HTTP["url"] =~ "^/git" {
        cgi.assign = ( "" => "" )
        setenv.add-environment = (
            "GIT_PROJECT_ROOT" => "/srv/git",
            "GIT_HTTP_EXPORT_ALL" => ""
        )
    }

> But if you drop the protections on "/git-receive-pack$", then an
> attacker can just POST whatever they want into your repository.

This setup is for a server on the internal network, but still, your
comment holds.  The reason for wanting to allow reading without
authentication is that then I can signal a CI server to pull without
having to give it credentials.

/M

[1]: The configuration for the authentication looks like this at the
moment, but it's only for testing:

    auth.backend = "plain"
    auth.backend.plain.userfile = "/srv/git/pwds.plain"
    auth.require = (
        "/" => (
            "method" => "basic",
            "realm" => "git",
            "require" => "valid-user"
            )
        )
-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus@therning.org   jabber: magnus@therning.org
twitter: magthe               http://therning.org/magnus

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
     -- Alan Kay

[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]

  reply	other threads:[~2013-04-10 20:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09  5:45 git-http-backend: anonymous read, authenticated write Magnus Therning
2013-04-09 12:24 ` Jakub Narębski
2013-04-10 20:53   ` Magnus Therning
2013-04-09 17:12 ` Jeff King
2013-04-10 20:45   ` Magnus Therning [this message]
2013-04-10 21:53     ` Jeff King
2013-04-10 21:30   ` Jakub Narębski
2013-04-10 21:47     ` Jeff King
2013-04-10 23:19       ` Magnus Therning
2013-04-11  1:56         ` Jeff King
2013-04-11  3:30           ` [PATCH 0/2] http-backend documentation examples Jeff King
2013-04-11  3:32             ` [PATCH 1/2] doc/http-backend: clarify "half-auth" repo configuration Jeff King
2013-04-11  6:57               ` Magnus Therning
2013-04-11  3:36             ` [PATCH 2/2] doc/http-backend: give some lighttpd config examples Jeff King
2013-04-11 16:47               ` Jakub Narębski
2013-04-11 17:02                 ` Jeff King
2013-04-11 18:27                   ` Jakub Narębski
2013-04-13  3:33                   ` [PATCH 3/2] doc/http-backend: match query-string in apache half-auth example Jeff King
2013-04-13  8:52                     ` Jakub Narębski
2013-04-11  6:52           ` git-http-backend: anonymous read, authenticated write Magnus Therning
2013-04-11 19:34             ` Jeff King
2013-04-12  7:22               ` Magnus Therning
2013-04-11 16:43           ` Jakub Narębski

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=20130410204544.GA2472@mteis.lan \
    --to=magnus@therning.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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).