Re: Невозможно изменить document root
SELinux?
On Wed, 28 Jan 2015 01:10:21 -0500
"Dmitrij" wrote:
> Приветствую!
>
> Столкнулся со странным поведение Nginx. Никогда такого не наблюдал
> ранее. Если вкратце, то при указании любой root директории отличной от
> /usr/share/nginx/html для отсутствующего файла возвращается 404, для
> существующего возвращается 403 с соответствующей ошибкой в логе:
>
> 2015/01/28 09:02:00 [error] 29646#0: *1 "/srv/www/default/index.html"
> is forbidden (13: Permission denied), client: 109.172.78.32, server:
> dig.tips, request: "GET / HTTP/1.1", host: "dig.tips"
>
> 1. Права на весь путь от корня к root сайта выставлены
> 2. Права на /var/lib/nginx/tmp выставлены
>
> Вот nginx.conf:
>
> user nginx;
> worker_processes 1;
>
> error_log /var/log/nginx/error.log;
> #error_log /var/log/nginx/error.log notice;
> #error_log /var/log/nginx/error.log info;
>
> pid/var/run/nginx.pid;
>
> events {
> worker_connections 1024;
> }
>
>
> http {
> include /etc/nginx/mime.types;
> default_type application/octet-stream;
>
> log_format main '$remote_addr - $remote_user [$time_local]
> "$request" '
> '$status $body_bytes_sent "$http_referer" '
> '"$http_user_agent" "$http_x_forwarded_for"';
>
> client_header_buffer_size1k;
> large_client_header_buffers 4 4k;
>
> gzip on;
> sendfile on;
> index index.php;
>
> include /etc/nginx/conf.d/*.conf;
> }
>
>
> Вот примитивный конфиг хоста, который работает с одним root и не
> работает с другим
>
> server {
> listen 80;
> server_name dig.tips;
> root /srv/www/default;
> # root /usr/share/nginx/html;
> location / {
> index index.html;
> }
> }
>
> Платформа: VPS flops.ru, Centos 6.5. Ставил разные версии nginx,
> результат одинаковый. Сложилось ощущение, что document_root где-то
> захардкодили. Кто сталкивался?
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,256299,256299#msg-256299
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Warm Regards,
Aleksei Miheev
mailto:alek...@miheev.info | xmpp:alek...@miheev.info
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
28 января 2015 г., 9:10 пользователь Dmitrij написал: > Приветствую! > > Столкнулся со странным поведение Nginx. Никогда такого не наблюдал ранее. > Если вкратце, то при указании любой root директории отличной от > /usr/share/nginx/html для отсутствующего файла возвращается 404, для > существующего возвращается 403 с соответствующей ошибкой в логе: > > 2015/01/28 09:02:00 [error] 29646#0: *1 "/srv/www/default/index.html" is > forbidden (13: Permission denied), client: 109.172.78.32, server: dig.tips, > request: "GET / HTTP/1.1", host: "dig.tips" > > 1. Права на весь путь от корня к root сайта выставлены > Нужны еще права на промежуточные папки. Они есть? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего обеда. Я ж developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь делать все нормально, однако за тенденциями не слежу. Все решается выключением SELinux. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256299,256302#msg-256302 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
On 28 Jan 2015, at 10:02, Dmitrij wrote: > По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова > "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего обеда. Я ж > developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь делать все > нормально, однако за тенденциями не слежу. > > Все решается выключением SELinux. JFYI: http://nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
Andrei Belov писал(а) в своём письме Wed, 28 Jan 2015 13:08:43 +0600: On 28 Jan 2015, at 10:02, Dmitrij wrote: По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего обеда. Я ж developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь делать все нормально, однако за тенденциями не слежу. Все решается выключением SELinux. JFYI: http://nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/ ИМХО, очень зря решается выключением. В первую очередь разработчик приложения и мэйнтейнер должны знать и предоставить информацию о том, какие разрешения необходимы приложению для корректного выполнения, а в идеале еще и написать policy-файл. Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh (http://stopdisablingselinux.com/) -- 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
Re: Невозможно изменить document root
On 28/01/2015 10:26, Eugene Peregudov wrote: > Andrei Belov писал(а) в своём письме Wed, 28 Jan 2015 > 13:08:43 +0600: > >> >> On 28 Jan 2015, at 10:02, Dmitrij wrote: >> >>> По моему лицу текут слезы. Спасибо вам, Великий Человек за эти слова >>> "SELinux"! Мне эта штука пару литров крови выпила со вчерашнего >>> обеда. Я ж >>> developer, сижу себе, пилю код, что-то тыкаю в сервере, стараюсь >>> делать все >>> нормально, однако за тенденциями не слежу. >>> >>> Все решается выключением SELinux. >> >> JFYI: >> http://nginx.com/blog/nginx-se-linux-changes-upgrading-rhel-6-6/ >> > ИМХО, очень зря решается выключением. В первую очередь разработчик > приложения и мэйнтейнер должны знать и предоставить информацию о том, > какие разрешения необходимы приложению для корректного выполнения, а в > идеале еще и написать policy-файл. Разрешения, упакованные в selinux-policy-targeted, вполне работают для конфигурации по-умолчанию. Если пользователь пакета меняет эту конфигурацию, логично и поменять правила для SELinux. Разрешать при этом на уровне пакета любые действия, которые может предпринять будущий пользователь, кажется еще большим злом, чем полное выключение SELinux этим самым пользователем. > Каждый раз когда кто-то выключает SELinux где-то плачет Dan Walsh > (http://stopdisablingselinux.com/) -- Konstantin Pavlov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
Нет, вы не поняли. Я не веду речь о том, что не буду использовать технологию. Просто я не был в курсе и долбился с локализацией проблемы целый вечер. Лог Nginx писал сообщение, которое было стандартным для ситуации с кривыми правами на файл или его предка. А сейчас мне просто нужно было поднять машину для тестов, ничего серьезного и критичного. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,256299,256326#msg-256326 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
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
Re: Невозможно изменить document root
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 :
> 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.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
Коллега Juriy Strashnov опередил :)
В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
запрещающее действие SELinux не пройдет мимо audit.log, также можно
поставить setroubleshoot-server, который будет писать все происходящее в
messages.
Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
машинах:
Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
вырабатывается набор разрешающих правил еще на машине разработчика. На
этом этапе уже становится ясно в деталях какие дополнительные разрешения
(с поправкой на пути) необходимо применить администратору при деплое
приложения.
Напротив, если разработка ведется без включенного селинукс, после деплоя
начинается многократный рефрен:
"ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
написание правил\установка правильных меток"
Причем, делать это приходится администратору порой без знания матчасти
самого приложения, что добавляет трудностей.
Juriy Strashnov писал(а) в своём письме 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 :
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
Re: Невозможно изменить document root
On 02.02.2015 15:10, Eugene Peregudov wrote: В любой непонятной ситуации - смотрите логи, там все есть. Ни одно запрещающее действие SELinux не пройдет мимо audit.log Это не совсем так, dontaudit AVC denials не логгируются. Подробнее: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Possible_Causes_of_Silent_Denials.html Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае вырабатывается набор разрешающих правил еще на машине разработчика. На этом этапе уже становится ясно в деталях какие дополнительные разрешения (с поправкой на пути) необходимо применить администратору при деплое приложения. Напротив, если разработка ведется без включенного селинукс, после деплоя начинается многократный рефрен: "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс -> написание правил\установка правильных меток" Причем, делать это приходится администратору порой без знания матчасти самого приложения, что добавляет трудностей. В некоторых/почти всех ситуациях использование OpenVZ дает такую же или даже еще лучшую изоляцию приложений без подобных танцев с бубном. Или Docker - там деплой приложения происходит еще проще для сисадминов, хотя уровень изоляции/надежности там будет меньше чем в случае с OpenVZ. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
selinux хорошо для "compliance". типа у вас какое-то госучреждение или типа того, есть политика безопасности, регулярный аудит, и есть "соответствие требованиям" в виде включенной галочки selinux а во всех нормальных случаях - selinux просто мешает жить 2 февраля 2015 г., 16:33 пользователь denis написал: > 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 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
если вы специально делаете так, что у вас промышленные сервера и
тестовые настроены по-разному - да, у вас проблема.
2 февраля 2015 г., 18:10 пользователь Eugene Peregudov
написал:
> Коллега Juriy Strashnov опередил :)
>
> В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
> запрещающее действие SELinux не пройдет мимо audit.log, также можно
> поставить setroubleshoot-server, который будет писать все происходящее в
> messages.
>
> Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
> машинах:
>
> Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
> вырабатывается набор разрешающих правил еще на машине разработчика. На этом
> этапе уже становится ясно в деталях какие дополнительные разрешения (с
> поправкой на пути) необходимо применить администратору при деплое
> приложения.
>
> Напротив, если разработка ведется без включенного селинукс, после деплоя
> начинается многократный рефрен:
> "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
> написание правил\установка правильных меток"
> Причем, делать это приходится администратору порой без знания матчасти
> самого приложения, что добавляет трудностей.
>
> Juriy Strashnov писал(а) в своём письме 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 :
>>
>> 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Невозможно изменить document root
> selinux хорошо для "compliance". типа у вас какое-то госучреждение или
типа того, есть политика безопасности, регулярный аудит, и есть
"соответствие требованиям" в
виде включенной галочки selinux
т.е. если ломанут ком-кий проект и уведут у вас базу данных, это нормально?
:) SELinux включают не для галочки, и да конечно же он не гарантирует 100%
безопасности в случае взлома, но он гарантирует, что взломщикам будет на
порядок сложнее получить необходимый результат
> а во всех нормальных случаях - selinux просто мешает жить
вы не любите кошек? Да вы просто не умеете их готовить!
2015-02-03 4:53 GMT+02:00 Илья Шипицин :
> если вы специально делаете так, что у вас промышленные сервера и
> тестовые настроены по-разному - да, у вас проблема.
>
> 2 февраля 2015 г., 18:10 пользователь Eugene Peregudov
> написал:
> > Коллега Juriy Strashnov опередил :)
> >
> > В любой непонятной ситуации - смотрите логи, там все есть. Ни одно
> > запрещающее действие SELinux не пройдет мимо audit.log, также можно
> > поставить setroubleshoot-server, который будет писать все происходящее в
> > messages.
> >
> > Offtop :Почему я за то, чтобы не выключать селинукс даже на девелоперских
> > машинах:
> >
> > Лучше пусть селинукс "бъёт по рукам" во время разработки, в таком случае
> > вырабатывается набор разрешающих правил еще на машине разработчика. На
> этом
> > этапе уже становится ясно в деталях какие дополнительные разрешения (с
> > поправкой на пути) необходимо применить администратору при деплое
> > приложения.
> >
> > Напротив, если разработка ведется без включенного селинукс, после деплоя
> > начинается многократный рефрен:
> > "ошибка полномочий -> греп логов -> расшифровка сообщений селинукс ->
> > написание правил\установка правильных меток"
> > Причем, делать это приходится администратору порой без знания матчасти
> > самого приложения, что добавляет трудностей.
> >
> > Juriy Strashnov писал(а) в своём письме 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 :
> >>
> >> 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
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
h
