Django, nginx, FastCGI - rodando via sockets unix, problemas de permissão

Question

Eu configurei o nginx para executar o site django via socket:

fastcgi_pass unix:/tmp/django.socket;

agora estou executando (manualmente)

./manage.py runfcgi socket=/tmp/django.socket

link

connect() to unix:/tmp/django.socket failed (13: Permission denied) while connecting to upstream,

quais permissões devo definir para poder reiniciar o django fcgi facilmente?

    

Answer 1

O Nginx está rodando sob algum usuário (no Debian geralmente é www-data), você pode verificar por:

ps aux | grep nginx | grep worker

O usuário estará na primeira coluna.

Este usuário tem que ter acesso ao /tmp/django.socket para escrever e ler. Você pode resolvê-lo executando django sob o mesmo usuário que o nginx está rodando (isto é, www-data no Debian), ou você precisa adicionar o usuário nginx ao mesmo grupo, como usuário, sob o qual você está executando o django tem permissão para ler e escrever para o grupo.

A primeira solução é mais simples e (para mim) melhor.

    

Answer 2

Eu tive exatamente esse problema. Eu estava rodando o django-site no Gunicorn rodando via unix socket (no fedora 19). Mas o nginx não estava começando. Eu vi o arquivo nginx-errors.log

2014/03/15 04:25:01 [crit] 18309#0: *422 connect() to unix:/webapps/django/run/gunicorn.sock failed (13: Permission denied) while connecting to upstream

Eu configurei todas as permissões e proprietários de arquivos corretamente. No final, aprendi que isso é devido ao SElinux e encontrei a solução aqui

UPDATE

seguindo no primeiro comentário

A solução descrita no link que forneci é muito longa. Então, estou copiando parte dessa solução aqui -

Uma solução rápida é desativar o selinux

setenforce 0

Este comando desabilita o selinux para todos os programas. Para permitir que o nginx leia o soquete unix enquanto o selinux estiver ativado, siga este procedimento -

Por padrão, as mensagens de log do SELinux são gravadas em /var/log/audit/audit.log através do sistema de auditoria do Linux. Se o daemon auditd não estiver em execução, as mensagens serão gravadas em /var/log/messages . As mensagens de log do SELinux são rotuladas com a palavra-chave AVC para que possam ser facilmente filtradas de outras mensagens, como no grep.

Então, ao greping nginx em /var/log/audit/audit.log , encontrei aquelas mensagens relativas do AVC, que indicam de fato uma negação da conexão nginx ao gitlab.socket.

type=AVC msg=audit(1377542938.307:248364): avc:  denied  { write } for  pid=2597 comm="nginx" name="gitlab.socket" dev="vda1" ino=1180273 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=sock_file
type=AVC msg=audit(1377542938.307:248364): avc:  denied  { connectto } for  pid=2597 comm="nginx" path="/home/git/gitlab/tmp/sockets/gitlab.socket" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket'

Usando uma ferramenta chamada audit2allow, podemos limpar as mensagens do AVC. Se você não o tiver instalado, ele será enviado com o pacote policycoreutils-devel.

grep nginx /var/log/audit/audit.log | audit2allow

e o resultado é:

#============= httpd_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_t http_cache_port_t:tcp_socket name_connect;

# !!! This avc is allowed in the current policy
allow httpd_t httpd_log_t:file setattr;

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_content_t:sock_file write;

#!!!! This avc is allowed in the current policy
allow httpd_t initrc_t:unix_stream_socket connectto;

#!!!! This avc is allowed in the current policy
allow httpd_t user_home_dir_t:dir search;

#!!!! This avc is allowed in the current policy
allow httpd_t user_home_t:dir { search getattr };

#!!!! This avc is allowed in the current policy
allow httpd_t user_home_t:sock_file write;

#!!!! This avc is allowed in the current policy
allow httpd_t var_run_t:file { read write };

Estas são as políticas que devem ser usadas com o SELinux. Observe que user_home é essencial, pois o APP_ROOT do GitLab está em / home / git /. Da mesma forma, você observa uma política relacionada à conexão de soquete recusada: unix_stream_socket connectto.

Em seguida, podemos usar o audit2allow para criar um módulo de política personalizado para permitir essas ações:

grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp'

Podemos verificar o módulo de política carregado corretamente listando os módulos carregados com semodule -l.

Depois disso, lembre-se de habilitar o SELinux novamente com setenforce 1.