Por que o nginx não consegue acessar o puma socket no CentOS 7?

Question

Portanto, eu tenho um aplicativo Ruby on Rails em /var/www/ de propriedade de nginx com 755 permissões. Disse app destina-se a ser implantado via puma.

Assim:

rvmsudo -u nginx bundle exec puma -e production -d -b unix:///var/www/my_app/tmp/sockets/my_app.socket

As permissões para o soquete são:

srwxrwxrwx. 1 nginx nginx 0 Nov  6 09:43 tmp/sockets/my_app.sock

O processo é, obviamente, de propriedade do nginx:

nginx     7335  0.0  8.8 536744 90388 ?        Sl   09:43   0:00 puma 2.9.2 (unix:///var/www/my_app/tmp/sockets/my_app.sock)

Minha configuração de configuração nginx é a seguinte:

upstream my_app {
  server unix:///var/www/my_app/tmp/sockets/my_app.sock;
}

server {
  listen 80;
  server_name www.example.com example.com;
  root /var/www/my_app/public;

  location / {
    proxy_pass http://my_app;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Tudo isso e meu aplicativo ainda têm permissões negadas.

connect() to unix:///var/www/my_app/tmp/sockets/my_app.sock failed (13: Permission denied) while connecting to upstream,

Eu tentei tudo isso como usuário root também. Mas ainda não funciona.

Alguém sabe o que estou fazendo errado?

    

Answer 1

Aleluia! Tudo isso acabou sendo um problema de política do SELinux especificamente relacionado ao nginx. Depois de horas de escavação, descobri tais negações executando:

sudo grep nginx /var/log/audit/audit.log

As mensagens pareciam assim:

type=AVC msg=audit(1415283617.227:1386): avc:  denied  { write } for  pid=1683 comm="nginx" name="my_app.sock" dev="tmpfs" ino=20657 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file

Para corrigir isso, encontrei um artigo maravilhoso de Axilleas .

Para criar a política que contém as permissões necessárias, tive que instalar o audit2allow e executar:

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

Uma vez concluído, finalizei a política com:

semodule -i nginx.pp

Infelizmente, tive que executar esse processo duas vezes antes de poder acessar meu aplicativo, pois eram necessárias políticas adicionais. No entanto, aqui estava a solução.

Além disso, há outro artigo interessante por Sergiy Krylkov .

Moral da história: aprenda o SELinux.