контексты 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 в permissive с помощью # 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 обратно в принудительное с sudo setenforce Enforcing. (в стороне изменения в SELinux с setenforce не переживут перезагрузки).
если SELinux является проблемой, вы должны найти правильный контекст, что сценарии должны быть, или, может быть, его простое исправление с логическим.
если вы находитесь в своем домашнем каталоге, это может быть так же просто, как установка SELinux логический. Для просмотра booleans, есть описание CentOS booleans здесь но я заметил, что мой пример user_exec_content ниже не указан там, более удобным инструментом для булевых описаний является 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
...
первый выкл показывает его текущее состояние, что он в настоящее время установлен в положение off; следующий выкл показывает по умолчанию, это означает, что он будет по-прежнему быть выключен После перезагрузки или перезапуска файловой системы.
в этом случае использовать #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 но я подозреваю, что вы где-то еще если у тебя такие проблемы.
Komp
3614
