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 с помощью 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 но я подозреваю, что вы находитесь где-то еще, если у вас возникли эти проблемы.
