<!DOCTYPE html><html><head>
<style type="text/css">body { font-family:'Consolas'; font-size:13px}</style>
</head>
<body><div>Коллега Juriy Strashnov опередил :) </div><div><br></div><div>В любой непонятной ситуации - смотрите логи, там все есть. Ни одно запрещающее действие SELinux не пройдет мимо audit.log, также можно поставить setroubleshoot-server, который будет писать все происходящее в messages.</div><div><br></div><div>Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских машинах:</div><div><br></div><div>Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае вырабатывается набор разрешающих правил еще на машине разработчика. На этом этапе уже становится ясно в деталях какие дополнительные разрешения (с поправкой на пути) необходимо применить администратору при деплое приложения.</div><div><br></div><div>Напротив, если разработка ведется без включенного селинукс, после деплоя начинается многократный рефрен: </div><div>"ошибка полномочий -> греп логов -> расшифровка сообщений селинукс -> написание правил\установка правильных меток"</div><div>Причем, делать это приходится администратору порой без знания матчасти самого приложения, что добавляет трудностей.</div><div><br></div><div>Juriy Strashnov <juriy.foboss@gmail.com> писал(а) в своём письме Mon, 02 Feb 2015 18:24:39 +0600:<br></div><br><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><div dir="ltr"><div>SELinux умеет объяснять, что делает. Однако получение этой информации требует некоторых усилий. Например для вышеописанного случая с блокировкой SSH диагностику можно провести так:<br><br>grep sshd /var/log/audit/audit.log | audit2why</div><div><br></div><div>Получим сообщение:</div><div><i><br>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</i><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-02 14:33 GMT+03:00 denis <span dir="ltr"><<a href="mailto:denis@webmaster.spb.ru" target="_blank">denis@webmaster.spb.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">28.01.2015 10:26, Eugene Peregudov пишет:<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
ИМХО, очень зря решается выключением. В первую очередь разработчик приложения и мэйнтейнер должны знать и предоставить информацию о том, какие разрешения необходимы приложению для корректного выполнения, а в идеале еще и написать policy-файл.<br>
<br>
Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh (<a href="http://stopdisablingselinux.com/" target="_blank">http://stopdisablingselinux.com/</a>)<br>
<br>
</blockquote></span>
До тех пор, пока оно будет включено по умолчанию - все инструкции будут начинаться с "выключите selinux", потому что обычно настройка делается так - селинух выкл или в permissive, нормальная настройка всего что запускаем и разворачиваем, а потом уже смотрим по результату, какие права нужны.<br>
Плюс, пока нет чётких ошибок "selinux: на файле XXX нет прав на YYY", первым шагом диагностики всегда будет его отключение. Это как при сетевой мистике обычно первый шаг - отключить фаервол. Это неправильно, но сразу становится понятно, кто виноват.<br>
До кучи - рабочим и тестовым машинам selinux больше мешает чем помогает, и там выключить совсем - нормальное действие.<br>
<br>
Из самого банального: ssh, авторизация по ключам, .ssh создан, права 0700, authorized_keys создан, права 0600, все владельцы правильные. Ключ не принимало, пока не выключили selinux (!). В логах ничего про то, что выполнена блокировка селинухом. Итог: я тоже приучился первым делом выключать это зло, пока оно не научится само и внятно говорить, что не так.<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best regards, Juriy Strashnov<br><br>Mob. +7 (953) 742-1550<br>E-mail: <a href="mailto:j.strashnov@me.com" target="_blank">j.strashnov@me.com</a><br><br>Please consider the environment before printing this email.</div>
</div>
</blockquote><br><br><br><div id="M2Signature"><div>-- </div><div>With best regards, Eugene JONIK Peregudov<br>mailto: eugene.peregudov@gmail.com</div></div></body></html>