Re: git-http-backend: anonymous read, authenticated write

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx   jabber: magnus@xxxxxxxxxxxx
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: pgp9babptzCZm.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]