nginx under supervisor can't open conf file - nginx

Question

This is very puzzling:
I'm on RHEL 7.5, trying to run Nginx 1.14.0 under Supervisor 3.3.4. The ultimate aim is to serve a Django site.
My "/etc/init.d/supervisord" looks like this:
#!/bin/sh
...
# Source init functions
. /etc/rc.d/init.d/functions
prog="supervisord"
prog_bin="/bin/supervisord -c /etc/supervisord.conf"
PIDFILE="/var/run/$prog.pid"
start()
{
echo -n $"Starting $prog: "
daemon $prog_bin --pidfile $PIDFILE
sleep 1
[ -f $PIDFILE ] && success $"$prog startup" || failure $"$prog startup"
echo
}
... # "stop", "restart" functions, etc.
"/etc/supervisord.conf" looks like this:
[unix_http_server]
file=/var/run//supervisor.sock
[supervisord]
logfile=/var/log/supervisor/supervisord.log
pidfile=/var/run/supervisord.pid
childlogdir=/var/log/supervisor
[rpcinterface:supervisor]
supervisor.rpcinterface_factory =
supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run//supervisor.sock
[include]
files = /etc/supervisor/conf.d/*.conf
"/etc/supervisor/conf.d/" has just one file in it: nginx.conf:
[program:nginx]
user=root
command=/usr/sbin/nginx -c /path/to/site/etc/nginx.conf
autostart=true
autorestart=true
startretries=3
redirect_stderr=True
Invoking the above command directly with sudo /usr/sbin/nginx -c /path/to/site/etc/nginx.conf & is successful. It starts right up and I can see the nginx processes with ps -ef
But if I start supervisor d like this:
$ sudo /etc/init.d/supervisord restart
It fails to launch Nginx:
$ sudo cat /var/log/supervisor/nginx-stdout---supervisor-tqI97D.log
nginx: [emerg] open() "/path/to/site/etc/nginx.conf" failed (13: Permission denied)
Permissions to read that file are good all the way down. Of course, the path is not actually called "/path/to/site/etc/nginx.conf", but there's an "x" for all users on every directory and a "r" for all users on the conf file itself:
$ namei -om /path/to/site/etc/nginx.conf
f: /path/to/site/etc/nginx.conf
dr-xr-xr-x root root /
drwxr-xr-x root root path
drwxr-xr-x root root to
drwxrwxr-x user1 group1 site
drwxrwxr-x user1 group1 etc
-rw-r--r-- root group1 nginx.conf
How can there be an error on an "open()" operation for this file? I've tried changing the "user" to root in "/etc/supervisor/conf.d/nginx.conf" and/or in "/etc/supervisord.conf" but the result is always the same.
Could the fact that this is SELinux make a difference? It's currently activated.
$ getenforce
Enforcing
If it helps, the nginx.conf file that can't be opened looks like this:
user nginx;
daemon off;
error_log /path/to/site/var/log/nginx-error.log warn;
pid /path/to/site/var/run/nginx.pid;
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /path/to/site/var/log/nginx-access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
upstream app_server {
server unix:/path/to/site/var/run/my-django.socket fail_timeout=0;
}
server {
listen 8000;
server_name xxx.xxx.xxx.xxx;
charset utf-8;
location /media {
alias /path/to/site/htdocs/media;
}
location /static {
alias /path/to/site/htdocs/static;
}
location / {
uwsgi_pass app_server;
include /path/to/site/etc/uwsgi_params;
}
}
}
Does anyone have any ideas?

Answer 1

I suggest you check with SELinux to really grasp the whole concept before doing anything to a production machine.
The httpd_t context permits NGINX to listen on common web server ports, to access configuration files in /etc/nginx, and to access content in the standard docroot location (/usr/share/nginx). It does not permit many other operations, such as proxying to upstream locations or communicating with other processes through sockets.
Once you are a king at SELinux (hah) check out NGINX's - Modifying SELinux Settings
Let us know, good luck!

Answer 2

On SELinux enabled systems process and files have security labels. SELinux policy contains the allowed access patterns between these labels. Access is denied if there is not a rule allowing the access.
The security labels on your nginx files seem to be incorrect: the AVC error message tells that access was denied for a process in httpd_t domain trying to access a file with default_t label. To allow access, you need to assign suitable security contexts to your nginx files. Possible contexts are documented in httpd_selinux man page. For configuration files, an approriate context would be httpd_config_t and for user content perhaps httpd_user_content_t.
You can manually apply a new security context to a file using chcon tool. After you have decided the security contexts to use, you should save them in file context database using semanage. Otherwise automatic relabeling will label the files incorrectly.
I've written a more detailed answer on the topic on related Unix & Linux Stack exchange question Configure SELinux to allow daemons to use files in non-default locations.