Коллега Juriy Strashnov опередил :)
В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
запрещающее действие SELinux не пройдет мимо audit.log, также можно
поставить setroubleshoot-server, который будет писать все происходящее в
messages.
Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
машинах:
Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
вырабатывается набор разрешающих правил еще на машине разработчика. На
этом этапе уже становится ясно в деталях какие дополнительные разрешения
(с поправкой на пути) необходимо применить администратору при деплое
приложения.
Напротив, если разработка ведется без включенного селинукс, после деплоя
начинается многократный рефрен:
"ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
написание правил\установка правильных меток"
Причем, делать это приходится администратору порой без знания матчасти
самого приложения, что добавляет трудностей.
Juriy Strashnov <juriy.fob...@gmail.com> писал(а) в своём письме Mon, 02
Feb 2015 18:24:39 +0600:
SELinux умеет объяснять, что делает. Однако получение этой информации
требует некоторых усилий. Например для >вышеописанного случая с
блокировкой SSH диагностику можно провести так:
grep sshd /var/log/audit/audit.log | audit2why
Получим сообщение:
type=AVC msg=audit(1382808690.186:75768): avc: denied { read } for
pid=26463 comm="sshd" name="authorized_keys2" >dev=dm-0 ino=1441809
scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023
>tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
2015-02-02 14:33 GMT+03:00 denis <de...@webmaster.spb.ru>:
28.01.2015 10:26, Eugene Peregudov пишет:
ИМХО, очень зря решается выключением. В первую очередь разработчик
приложения и мэйнтейнер должны знать и >>>предоставить информацию о
том, какие разрешения необходимы приложению для корректного
выполнения, а в идеале >>>еще и написать policy-файл.
Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh
(http://stopdisablingselinux.com/)
До тех пор, пока оно будет включено по умолчанию - все инструкции будут
начинаться с "выключите selinux", >>потому что обычно настройка
делается так - селинух выкл или в permissive, нормальная настройка
всего что >>запускаем и разворачиваем, а потом уже смотрим по
результату, какие права нужны.
Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY",
первым шагом диагностики всегда будет его >>отключение. Это как при
сетевой мистике обычно первый шаг - отключить фаервол. Это неправильно,
но сразу >>становится понятно, кто виноват.
До кучи - рабочим и тестовым машинам selinux больше мешает чем
помогает, и там выключить совсем - нормальное >>действие.
Из самого банального: ssh, авторизация по ключам, .ssh создан, права
0700, authorized_keys создан, права 0600, >>все владельцы правильные.
Ключ не принимало, пока не выключили selinux (!). В логах ничего про
то, что >>выполнена блокировка селинухом. Итог: я тоже приучился первым
делом выключать это зло, пока оно не научится >>само и внятно говорить,
что не так.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--Best regards, Juriy Strashnov
Mob. +7 (953) 742-1550
E-mail: j.strash...@me.com
Please consider the environment before printing this email.
--
With best regards, Eugene JONIK Peregudov
mailto: eugene.peregu...@gmail.com
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
