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

[Eugene Peregudov]

Коллега 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150202/b751fed1/attachment-0001.html>