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

-- selinux mailing list selinux@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org