Such an issue might depend on the OS you use and how it is configured. Some linux distros (mainly those based on RHEL like CentOS or Fedora) come with SELinux activated by default. This can be checked, and temporarily changed, with the following commands:
root@ls:~# /usr/sbin/setenforce Permissive
You can also have a more complete view on the current configuration with:
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
This change can be made permanent by editing the
/etc/selinux/config file and set the
SELINUX variable to
But, the correct way to solve this kind of issue, if you are indeed in this situation, is to check the
/var/log/audit/audit.log log file. It will contain all the events related to SELinux rules. You'll then probably should give your script the correct context, i.e. being authorized to be run by the apache/php user. Checking SELinux security context is done with
root@ls:~# ls -alZ /var/www/cgi-bin/
drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t .
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t ..
This list the User, the Role and the Type of each file/directory. Here the
httpd_sys_script_exec_t type gives the files in the cgi directory the permission to be executed by httpd. Your shell script should probably have the same type.
You can also feed the
audit.log lines to the
audit2allow command. It will output you the changes needed to make SELinux happy. But usually the changes suggested need to be done on the SELinux policy itself which is not what you should do in your case (still, this output can give some clue at what is going on).
The following page describe a similar issue and different ways to solve it: http://sheltren.com/stop-disabling-selinux