1

I have the following setup for nginx and uwsgi to serve a cgit instance.

# cat /etc/uwsgi.d/cgit.ini 
[uwsgi]
plugins = cgi

uid = nginx
gid = nginx

socket = /srv/http/cgit/cgit.sock
procname-master = uwsgi cgit
processes = 1
threads = 2
cgi = /srv/http/cgit/htdocs/cgit.cgi

logto = /srv/http/cgit/logs/uwsgi.log

The uwsgi instance works (nothing weird in the configuration file) and the socket permissions seem right, in that nginx is the owner. I double checked, that the user nginx can access the directory and see the socket.

# ls -la /srv/http/cgit
total 20
drwxr-xr-x. 5 nginx nginx 4096 Oct 29 14:09 .
drwxr-xr-x. 3 nginx nginx 4096 Oct 29 12:59 ..
drwxrwxr-x. 6 nginx nginx 4096 Oct 29 14:06 build
srwxr-xr-x. 1 nginx nginx    0 Oct 29 14:28 cgit.sock
drwxr-xr-x. 2 nginx nginx 4096 Oct 29 14:06 htdocs
drwxr-xr-x. 2 nginx nginx 4096 Oct 29 13:54 logs

My nginx config says:

user nginx;

worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }

        location /cgit-web {
            rewrite ^/cgit-web(/.*)$ $1 break;
            root /srv/http/cgit/build;
        }

        location /cgit {
            try_files $uri @cgit;
        }

        location @cgit {
            gzip off;
            include uwsgi_params;
            uwsgi_modifier1 9;
            uwsgi_pass unix:/srv/http/cgit/cgit.sock;
        }

    }
}

User is nginx and the path to the socket file is also correct. Now, upon trying to access /cgit, I find the following message in nginx's error log:

*6 connect() to unix:/srv/http/cgit/cgit.sock failed (13: Permission denied) while connecting to upstream, client: x.x.x.x, server: _, request: "GET /cgit HTTP/1.1", upstream: "uwsgi://unix:/srv/http/cgit/cgit.sock:", host: "xxx"

Which permissions did I get wrong? Why can't nginx access the socket?


The issue was with SELinux. Thank you!

janoliver
  • 133
  • 1
  • 8
  • Is SElinux, AppArmor or similar running and perhaps blocking access? – JayMcTee Oct 29 '15 at 13:42
  • sestatus says, that SEliniux is running. I have zero experience with that (not my server...). How can I find out whether it is blocking access and how to solve the issue? – janoliver Oct 29 '15 at 13:57
  • You can briefly switch off SELinux with setenforce 0 then reload Nginx. If it then does work, you know it's SElinux. Remember to switch it back on with setenforce 1, you can then make policies or amend file tags to make it work with SElinux on. – JayMcTee Oct 29 '15 at 14:04
  • I simply installed cgit from the centos repos, which pulls httpd as a dependency and it works out of the box. As I said, it is not my server and I am afraid to mess up anything. – janoliver Oct 29 '15 at 14:10
  • You can also look in the audit.log log files for SElinux denied messages. But very briefly disabling SElinux cannot mess up anything, it is a very common way to test whether SElinux is blocking a certain request. – JayMcTee Oct 29 '15 at 14:25
  • Look at your audit log, and post the relevant entries here. – Michael Hampton Oct 29 '15 at 14:28

0 Answers0