带有git-http-backend的nginx:www-data用户对git push的访问权限不足

时间:2018-08-11 15:17:29

标签: git nginx permissions git-http-backend

我正在尝试使用fcgiwrap设置nginx,以将https://<host>/git/<repo>.git下的请求转发到git-http-backend。

服务器是刚安装的debian linux,因此在后台应该没有尴尬的事情。

错误情况

fcgiwrap套接字以www-data用户身份运行,并且应该有权访问git存储库(请参见下文)。但是,当尝试推送时,我得到下面的git消息(我认为是与访问权限有关的问题):

$ git push origin master
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), 385 bytes | 0 bytes/s, done.
Total 6 (delta 0), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database objects
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To https://xxx:xxx@127.0.0.1/git/test.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'https://xxx:xxx@127.0.0.1/git/test.git'

设置

nginx配置:

server {                                                                                                                                                                          
        server_name  xxxxxxx.com;                                                                                                                                        

        location ~ /git(/.*) {                                                                                                                                                    
                auth_basic      "Private Git Repository";                                                                                                                         
                auth_basic_user_file /etc/nginx/.htpasswd;                                                                                                                        

                # fcgiwrap is set up to listen on this host:port                                                                                                                  
                fastcgi_pass unix:/var/run/fcgiwrap.socket;                                                                                                                       
                include       fastcgi_params;
                fastcgi_param SCRIPT_FILENAME     /usr/lib/git-core/git-http-backend;
                # export all repositories under GIT_PROJECT_ROOT
                fastcgi_param GIT_HTTP_EXPORT_ALL "";
                fastcgi_param GIT_PROJECT_ROOT    /opt/git;
                fastcgi_param PATH_INFO           $1;
                fastcgi_param REMOTE_USER $remote_user;
        }
}

FastCGIWrap:

$ apt-get install fcgiwrap
$ cat /etc/init.d/fcgiwrap
...
FCGI_USER="www-data"
FCGI_GROUP="www-data"
# Socket owner/group (will default to FCGI_USER/FCGI_GROUP if not defined)
FCGI_SOCKET_OWNER="www-data"
FCGI_SOCKET_GROUP="www-data"
...

/ opt / git中的权限:

$ chown -R git:git /opt/git/
$ chmod -R 775 /opt/git/
$ chmod -R a+s /opt/git/
$ ls -la /opt/git                                                                                                                         0 !193 0jobs
drwsrwsr-x 6 git  git  4096 Aug 11 15:21 .
drwxr-xr-x 3 root root 4096 Jul 15 12:01 ..
drwsrwsr-x 7 git  git  4096 Aug 12 11:47 test.git

git repo配置:

$ cat /opt/git/test.git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedrepository = 1
        sharedRepository = 1
[receive]
        denyNonFastforwards = true
[http]
    receivepack = true

nginx用户是www-data组的成员git

$ groups www-data
www-data : www-data git
$ cat /etc/group | grep www-data
www-data:x:33:
git:x:1001:www-data

解决方法

  1. 奇怪的是,如果我chgrp -R www-data /opt/git/有效。我想将其设为git:git

  2. chmod a+s /usr/lib/git-core/git-http-*有效。现在,我也可以执行chmod -R 705 /opt/git/,它可以工作了。我想是因为现在root用户执行命令了。我怀疑这是安全的。因此,不应使用它...

  3. 使用ssh。使用ssh可以工作,甚至可以以用户www-data的身份登录并直接推送到存储库(因为正确设置了组权限!)。但是,这不是选项,因为需要https访问权限!

我想念什么?

我的想法不多了。 按ssh推送有效。 如果我做chown -R 770 /opt/git/,那么我什至无法再通过https克隆或获取。因此,似乎www-data用户无法通过git-http-backend cgi脚本进行访问。但为什么???该用户是git组的成员,应该具有组访问权限!

相关

1 个答案:

答案 0 :(得分:0)

重新启动!!

不敢相信... 一个简单的服务器reboot解决了这个问题。

我之所以尝试这种方法,是因为在向用户添加组权限时,我必须注销并重新登录。似乎许可内容有时并不即时应用?哇...