nginx master process running as root but complaining that it is not
I am running nginx 1.11.3, compiled from source with the addition of the ngx_cache_purge module, on Ubuntu 14.04.3 server.
I'm seeing in the nginx error.log the following:
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)
The two lines always come in one after the other. The odd thing is that the site seems to be served properly, and https also seems to be working, despite it claiming in that error there (I think) that it can't read the certificate chain.
In nginx.conf, I have the first line set to: user www-data www-data;
If I do ps aux | grep nginx
, I see that the master process IS running as root, and the worker and cache processes as www-data -- as it should be, I think. I'm starting nginx through sudo service nginx start
.
One thing I've noticed is that no matter what I've tried, OCSP stapling does not work. The only vague thought I've had is that when nginx tries to some part of the SSL negotiation, maybe it opens another process that needs to be root to access the letsencrypt/live/* directories, but that process is not being launched as root. Just a wild guess.
As for the /etc/letsencrypt directory, it is owned by root, has drwxr-xr-x set, live and archive subdirs set to drwx------, individual site folders within those set to drwxr-xr-x. Individual symlinks to keys/certs in live are set to lrwxrwxrwx and the actual keys/certs in archive are set to -rw-r--r--
There is one other question about this, but it went unanswered.
nginx -V output in case it is useful:
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'
I figured this out. For some of its https negotiation -- I think only the first https negotiation of each server block after nginx starts up -- nginx spins up a temporary root-user process that is then immediately closed as soon as the negotiation. For me, this was failing because I compiled nginx myself after previously having the repository version installed. Though I removed the standard version with apt-get remove
before installing my own compiled nginx, some part of the original's startup script was left behind, and when my new nginx was trying to spin up that process (and it seems only that process, no other part), it was failing. I solved by doing a complete apt-get remove --purge
and then reinstalling my compiled version.