On 08/15/2016 09:56 AM, JONIK NSK wrote:
Hi!
I did some research and have successfully solved topic's problem.
First issue is that the path /opt/netbox/netbox/netbox/gunicorn\.sock in
file context rule was not an real filesystem path, because the middle
netbox component was a symlink to netbox-1.x.x, therefore restorecon did
not work.
Second issue is that the daemon actually recreates the socket file, and
socket inherits its parent dir context (thanks to Philip for this hint),
therefore file actually has a usr_t context.
Thus, I created a directory/opt/netbox/run for the runtime-environment
and set on it the httpd_var_run_t file context:
# semanage fcontext -l | grep netbox
/opt/netbox/run(/.*)? all files system_u:object_r:httpd_var_run_t:s0
Next, I defined the socket path in my app configuration to this directory:
bind = 'unix:/opt/netbox/run/gunicorn.sock'
Finally, I restarted app, and the socket is created with the correct
context:
# ls -lZ /opt/netbox/run/gunicorn.sock
srwxrwxrwx. netbox nginx system_u:object_r:httpd_var_run_t:s0
/opt/netbox/run/gunicorn.sock
Hope that this will help someone.
Yeap, that's a nice solution. What is your directory structure under
/opt/netbox/run?
There is a chance to define a file context equivalence using
semanage-fcontext. So for example
# semanage fcontext -a -e / /opt/netbox
# restorecon -R -v /opt/netbox
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.