ACL и контексты SELinux совершенно разные. Там хороший учебник здесь для CentOS
Чтобы увидеть, действительно ли SELinux блокирует ваш доступ 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 в моем выводе говорится, что SELinux активно блокирует доступ вне контекста.
Временно установите SELinux для разрешения, используя # 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 Разрешительный режим все равно предупредит вас о нарушениях контекста SELinux, но не заблокирует их. Это хороший способ проверить, действительно ли проблема в SELinux. Если это было, и теперь все работает, установите SELinux обратно в Enforcing with sudo setenforce Enforcing. (В дополнение к изменениям SELinux с setenforce перезагрузка не переживет).
Если проблема в SELinux, вы должны найти правильный контекст, которым должны быть сценарии, или, может быть, это простое исправление с логическим значением.
Если вы находитесь в своем домашнем каталоге, это может быть так же просто, как установить логическое значение SELinux. Для просмотра булевых, есть описание CentOS булевых здесь, но я заметил мой user_exec_content ниже пример не в списке, более удобный инструментом для логических ленитесь и является semanage булева -l
# getsebool -a | grep exec ... user_exec_content --> off ... #sudo semanage boolean -l ... user_exec_content (off, off) Allow user to exec content ... Первое выключение показывает его текущее состояние, что в данный момент оно выключено; следующее отключение показывает значение по умолчанию, означающее, что оно все еще будет отключено после перезагрузки или перемаркировки файловой системы.
В этом случае использование #setsebool -P user_exec_content on флага -P делает логическое изменение постоянным при перезагрузке
Если это проблема контекста, хорошо, контексты гораздо приятнее работать, потому что они более интуитивно понятны. Кажется, что это проба, ошибка и опыт относительно того, что на самом деле делает то, что с булевыми значениями SELinux, например, не знаю, что на самом деле делает user_exec_content.
Используйте флаг -Z с ls для просмотра контекста ваших файлов, например. ls -alZ.
$ ls -alZ -rwxrwxr-x. trogdor trogdor unconfined_u:object_r:user_home_t:s0 backup.sh Здесь user_home_t является контекстом для backup.sh. Допустим, у вас есть другой каталог с правильными контекстами для выполнения сценариев, вы можете отразить этот контекст в каталоге ./scripts, используя:
# chcon -R --reference /onethatworks ./scripts Чтобы перепроверить изменения были использованы ls -alZ ./scripts
restorecon -Rv ./scripts должен перемаркировать файловую систему, рекурсивно перемаркируя все файлы и каталоги в соответствии с обновленными контекстами. В этом случае он просто делает каталог скриптов и его содержимое.
Если это сработает, внесенные изменения не сохранятся после перезагрузки, и вы можете использовать следующее, чтобы сделать это изменение постоянным.
# semanage fcontext -a -s system_u -t <context_that_worked> "./scripts(/.*)? Другим вариантом управления SELinux является установка, policycoreutils-guiчтобы вы могли войти в графический интерфейс конфигурации selinux, введя # system-config-selinux. С помощью фильтрации с использованием 'script' я обнаружил, что многие сценарии используют bin_t в качестве контекста. Вы также можете изменить режим принуждения с ним. Мои сценарии в моем домашнем каталоге успешно выполняются, user_home_tно я подозреваю, что вы находитесь где-то еще, если у вас возникли эти проблемы.