Você deve verificar a permissão, não apenas do soquete (arquivo), mas de todos os diretórios pai. Se qualquer deles negar acesso, sua solicitação falhará.
Por exemplo:
# ls -ld /home/app
drwx------. 8 root root 4096 Dec 7 21:33 /home/app
Dado: nova caixa Archlinux VPS na DigitalOcean. Eu criei um usuário, 'app', e há um arquivo, /home/app/webapp.sock
criado pelo binário iniciado pelo systemd:
[Unit]
Description=Web application server
After=network.target
[Service]
Type=forking
User=app
PIDFile=/home/app/webapp.pid
ExecStart=/home/app/.gem/ruby/2.0.0/bin/thin -d --user app -e production --chdir /home/app/app --socket /home/app/webapp.sock --pid /home/app/webapp.pid --log /home/app/log/webapp.log start
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -QUIT $MAINPID
[Install]
WantedBy=multi-user.target
Não quero executar este aplicativo como usuário http, pois em algum momento eu posso decidir executar outro servidor da Web nessa máquina com um usuário diferente, expondo apenas o arquivo .sock ao usuário http. O Rails é conhecido por ter falhas de segurança, então eu gostaria de evitar que o usuário 'app' chegue em qualquer lugar fora de sua pasta pessoal e seus próprios dados.
Eu tenho um usuário sudo, 'sudoer', e não há como ler nem mesmo um arquivo pid:
[sudoer@host ~]$ cat /home/app/webapp.pid
cat: /home/app/webapp.pid: Permission denied
[sudoer@host ~]$ sudo su - app
[app@host ~]$ ls -l webapp.pid
-rw-r--r-- 1 app app 5 Dec 7 19:33 webapp.pid
Tem direitos 'r' para 'outros', porque é que 'sudoer' não pode 'catar' isso?
Eu assumo que esta é a razão para os seguintes erros nginx também. Arquivo estático:
2013/12/07 18:58:05 [error] 18114#0: *2 open() "/home/app/app/public/favicon.ico" failed (13: Permission denied), client: 183.89.50.151, server: host.com, request: "GET /favicon.ico HTTP/1.1", host: "host.com"
Conteúdo dinâmico:
2013/12/07 20:49:00 [crit] 21581#0: *1 connect() to unix:/home/app/webapp.sock failed (13: Permission denied) while connecting to upstream, client: 183.89.50.151, server: host.com, request: "GET /favicon.ico HTTP/1.1", upstream: "http://unix:/home/app/webapp.sock:/favicon.ico", host: "host.com"
Trecho da configuração do nginx:
upstream webapp {
server unix:/home/app/webapp.sock fail_timeout=0;
}
server {
listen 80;
root /home/app/app/public;
Isso é segurança reforçada? SELinux? CGroups? O que estou fazendo errado?
Você deve verificar a permissão, não apenas do soquete (arquivo), mas de todos os diretórios pai. Se qualquer deles negar acesso, sua solicitação falhará.
Por exemplo:
# ls -ld /home/app
drwx------. 8 root root 4096 Dec 7 21:33 /home/app