ACLs and SELinux contexts are entirely different.
There's a good tutorial here for CentOS
To see if SELinux is actually what is blocking your access use sestatus
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
Enforcing
in my output says that SELinux is actively blocking out-of-context accesses.
Temporarily set SELinux to permissive using # sudo setenforce Permissive
$ sudo setenforce Permissive
[sudo] password for trogdor:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
Permissive mode will still alert you of SELinux context violations but will not block them. This is a good way to check if SELinux is actually the problem. If it was, and now everything works, set SELinux back to Enforcing with sudo setenforce Enforcing
. (as an aside changes to SELinux with setenforce will not survive reboot).
If SELinux is the problem you have to find the correct context that the scripts should be, or maybe its a simple fix with a boolean.
If you are in your home directory it could be as simple as setting an SELinux boolean. To view booleans, there's a description of CentOS booleans here but I notice my user_exec_content example below is not listed there, a more convenient tool for boolean discriptions is semanage boolean -l
# getsebool -a | grep exec
...
user_exec_content --> off
...
#sudo semanage boolean -l
...
user_exec_content (off , off) Allow user to exec content
...
The first off shows its current state, that it is currently set to off; the next off shows the default, meaning that it will still be off after reboot or file system relabeling.
In that case use #setsebool -P user_exec_content on
The -P flag makes the boolean change permanent across reboots
If it is a context problem, good, contexts are much nicer to work with because they are more intuitive. It seems to be trial, error and experience as to what actually does what with the SELinux booleans, for example, no idea what user_exec_content actually does.
Use the -Z flag with ls to view the context of your files, eg. ls -alZ.
$ ls -alZ
-rwxrwxr-x. trogdor trogdor unconfined_u:object_r:user_home_t:s0 backup.sh
Here user_home_t is the context for backup.sh.
Say you have another directory that has the correct contexts to execute scripts, you can mirror that context onto the ./scripts directory by using:
# chcon -R --reference /onethatworks ./scripts
To double-check the change was made use ls -alZ ./scripts
restorecon -Rv ./scripts
should relabel the filesystem, relabeling all the files and directories recursively to the updated contexts. In this case it is just doing the scripts directory and its contents.
If that works, the changes made here will not survive reboot, and you can use the following to make the change permanent.
# semanage fcontext -a -s system_u -t <context_that_worked> "./scripts(/.*)?
Another option for managing SELinux is to install policycoreutils-gui
so you have access to an selinux configuration gui by entering # system-config-selinux
. By filtering using 'script' I found that many scripts use bin_t as their context. You can also change the enforcing mode with it. My scripts in my home directory execute happily with user_home_t
but I suspect you are somewhere else if you're having these troubles.