nginx processo mestre executando como root, mas reclamando que não é

1

Estou executando o nginx 1.11.3, compilado da fonte com a adição do módulo ngx_cache_purge, no servidor Ubuntu 14.04.3.

Estou vendo no nginx error.log o seguinte:

2016/08/03 14:30:00 [warn] 21827#21827: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
2016/08/03 14:30:00 [emerg] 15611#15611: BIO_new_file("/etc/letsencrypt/live/XXXXXXX.com/fullchain.pem") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/letsencrypt/live/XXXXXXX.com/fullchain.pem','r') error:2006D002:BIO routines:BIO_new_file:system lib)

As duas linhas sempre aparecem uma depois da outra. O curioso é que o site parece ser servido corretamente, e o https também parece estar funcionando, apesar de afirmar que há erro (eu acho) que ele não pode ler a cadeia de certificados.

No nginx.conf, eu tenho a primeira linha definida como:     usuário www-data www-data;

Se eu fizer ps aux | grep nginx , vejo que o processo mestre está sendo executado como raiz e os processos de trabalho e cache como www-data - como deveria ser, eu acho. Eu estou começando o nginx através de sudo service nginx start .

Uma coisa que eu notei é que não importa o que eu tentei, o grampeamento OCSP não funciona. O único pensamento vago que tive foi que quando o nginx tenta alguma parte da negociação SSL, talvez ele abra outro processo que precisa ser root para acessar os diretórios letsencrypt / live / *, mas esse processo não está sendo lançado como root . Apenas um palpite.

Quanto ao diretório / etc / letsencrypt, ele é de propriedade de root, tem conjunto drwxr-xr-x, subdiretórios live e de archive definidos como drwx ------, pastas de sites individuais dentro daquelas definidas como drwxr-xr -x Os links simbólicos individuais para keys / certs em live são definidos como lrwxrwxrwx e as chaves / certificados reais no archive são configurados como -rw-r - r -

Existe uma outra pergunta sobre isso , mas ficou sem resposta.

saída nginx -V no caso de ser útil:

nginx version: nginx/1.11.3 built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) built with OpenSSL 1.0.2h 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-module=/opt/nginx_cachepurge_module/ngx_cache_purge --add-dynamic-module=debian/extra/njs-0.1.0/nginx --with-threads --with-stream --with-stream_ssl_module --with-stream_geoip_module=dynamic --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'

    
por Josh K 03.08.2016 / 20:46

2 respostas

0

Você deve tornar suas chaves privadas legíveis pelo grupo ssl-cert. Experimente

sudo chown -R root:ssl-cert /etc/letsencrypt/live/XXXXXXX.com/
    
por 03.08.2016 / 21:16
0

Eu percebi isso. Para algumas de suas negociações https - acho que apenas a primeira negociação https de cada bloco de servidor após o início do nginx - o nginx ativa um processo temporário de usuário root que é imediatamente encerrado assim que a negociação é iniciada. Para mim, isso estava falhando porque eu mesmo compilei o nginx depois de ter a versão do repositório instalada. Embora eu tenha removido a versão padrão com apt-get remove antes de instalar meu próprio nginx compilado, parte do script de inicialização do original foi deixada para trás, e quando meu novo nginx estava tentando rodar esse processo (e parece apenas esse processo, nenhum outro parte), estava falhando. Eu resolvi fazendo um apt-get remove --purge completo e depois reinstalando minha versão compilada.

    
por 04.08.2016 / 02:11