1

Итак, у меня есть куча скриптов bash & python которые я написал, все они просто объединяются в один большой каталог. Ну, на самом деле есть отдельные подкаталоги, но все они вложены в этот основной каталог.
Итак, ради аргумента, структура каталогов выглядит примерно так:

find . -type d
.
./scripts/sh
./scripts/sh/a
./scripts/sh/b
./scripts/sh/c
./scripts/py
./scripts/py/x
./scripts/py/y
./scripts/py/z

Как бы то ни было, я попытался сделать всю коллекцию скриптов исполняемой, одним махом с помощью find и chmod:

find . -type f -exec chmod +x {} +

Обычно это все, что мне нужно сделать, но я заметил, что бит +x все еще не установлен. Все их разрешения все еще выглядят так:

ls -l ./scripts/py/z
-rw-rw----.  1 root 1015  801 May  7 12:00 script_name.py

Возможно. . символ (завершающий флаги разрешений) подразумевает некоторый контекст безопасности SELinux со списком контроля доступа или подобным. Я проверил с getfacl , не зная, для чего искать; первый - это каталог, второй - один из файлов сценария:

getfacl -acp ./scripts/py/z &&
getfacl -acp ./scripts/py/z/*
user::rwx
group::rwx
other::--x

user::rw-
group::rw-
other::---

Я экспериментировал со следующими параметрами setfacl , но безрезультатно:

setfacl --help | grep 'remove'
  -x, --remove=acl        remove entries from the ACL(s) of file(s)
  -X, --remove-file=file  read ACL entries to remove from file
  -b, --remove-all        remove all extended ACL entries
  -k, --remove-default    remove the default ACL

Итак, в ситуации, когда права root пользователей не соблюдаются, а sudo бесполезен, я должен спросить; Как я могу восстановить контроль доступа к своим файлам?

Перенос с сайта security.stackexchange.com

1 ответ1

1

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .