Re: Невозможно изменить document root

[Илья Шипицин]

если вы специально делаете так, что у вас промышленные сервера и
тестовые настроены по-разному - да, у вас проблема.

2 февраля 2015 г., 18:10 пользователь Eugene Peregudov
<eugene.peregudov at gmail.com> написал:
> Коллега Juriy Strashnov опередил :)
>
> В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
> запрещающее действие SELinux не пройдет мимо audit.log, также можно
> поставить setroubleshoot-server, который будет писать все происходящее в
> messages.
>
> Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
> машинах:
>
> Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
> вырабатывается набор разрешающих правил еще на машине разработчика. На этом
> этапе уже становится ясно в деталях какие дополнительные разрешения (с
> поправкой на пути) необходимо применить администратору при деплое
> приложения.
>
> Напротив, если разработка ведется без включенного селинукс, после деплоя
> начинается многократный рефрен:
> "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
> написание правил\установка правильных меток"
> Причем, делать это приходится администратору порой без знания матчасти
> самого приложения, что добавляет трудностей.
>
> Juriy Strashnov <juriy.foboss at 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 <denis at 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 at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
>
> --
> Best regards, Juriy Strashnov
>
> Mob. +7 (953) 742-1550
> E-mail: j.strashnov at me.com
>
> Please consider the environment before printing this email.
>
>
>
>
> --
> With best regards, Eugene JONIK Peregudov
> mailto: eugene.peregudov at gmail.com
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru