Я работаю над настройкой веб-сервера с RedHat Enterprise 6 с Apache и PHP внутри среды chroot jail. Каталог chroot для apache - / chroot / httpd. Я последовал за этот пример, но когда я запускаю apache, я вижу следующее в / var / log / httpd / error_log.
[warn] ./mod_dnssd.c: No services found to register
[Mon Jul 25 13:14:31 2011] [notice] core dump file size limit raised to 4294967295 bytes
[Mon Jul 25 13:14:31 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
[Mon Jul 25 13:14:31 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Jul 25 13:14:31 2011] [notice] Digest: generating secret for digest authentication ...
[Mon Jul 25 13:14:31 2011] [notice] Digest: done
[Mon Jul 25 13:14:31 2011] [notice] mod_chroot: changed root to /chroot/httpd.
[Mon Jul 25 13:14:31 2011] [error] (13)Permission denied: could not create /var/run/httpd.pid
[Mon Jul 25 13:14:31 2011] [error] httpd: could not log pid to file /var/run/httpd.pid
[Mon Jul 25 13:14:31 2011] [warn] ./mod_dnssd.c: No services found to register
Кроме того, SELinux включен, и в соответствии с инструкциями вы должны изменить значение логического httpd_disable_trans на 1 с помощью команды
setsebool httpd_disable_trans 1
Однако я не могу найти такое логическое значение под / selinux / логические или где-нибудь в системе. Команда выдает следующую ошибку:
Could not change active booleans: Invalid boolean
Я поискал в сети, почему этого логического значения нет в системе, но результата не было. Я понятия не имею, SELinux не позволяет запускать httpd или это проблема с разрешениями. Я дважды проверил разрешения, и они кажутся нормальными. Какие-либо предложения?
Спасибо.
Обновить: Я определил, что именно SELinux действительно является причиной этих ошибок. Изменение политики по умолчанию с принудительной на разрешающую позволяет apache запускаться нормально. Вопрос в том, почему httpd_disable_trans недоступен в системе? Это позволило бы мне поддерживать безопасность SELinux вместе с apache.
Кроме того, с другой стороны, с apache внутри среды chroot, лучше всего размещать веб-контент внутри / chroot или создавать символические ссылки оттуда, где он находится? Моя цель - включить веб-контент в пользовательских каталогах, хранящихся в / users.
Обновление 2: Некоторые строки конфигурации Apache, которые я считаю актуальными:
.....
ServerRoot /etc/httpd
LockFile /var/run/httpd.lock
CoreDumpDirectory /var/run
ScoreBoardFile /var/run/httpd.scoreboard
PidFile /var/run/httpd.pid
ChrootDir "/chroot/httpd"
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_alias_module modules/mod_authn_alias.so
LoadModule authn_anon_module modules/mod_authn_anon.so
LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_owner_module modules/mod_authz_owner.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_dbm_module modules/mod_authz_dbm.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule ldap_module modules/mod_ldap.so
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule env_module modules/mod_env.so
LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_module modules/mod_dav.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule info_module modules/mod_info.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule actions_module modules/mod_actions.so
LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule substitute_module modules/mod_substitute.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule cache_module modules/mod_cache.so
LoadModule suexec_module modules/mod_suexec.so
LoadModule disk_cache_module modules/mod_disk_cache.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule version_module modules/mod_version.so
LoadModule chroot_module /usr/lib/httpd/modules/mod_chroot.so
Include conf.d/*.conf
User apache
Group apache
....
Я просто разобрался, в чем проблема. Это наша среда:
RedHat 5 с последней версией apache RPM
Когда вы просматриваете журналы ошибок, он жалуется, что не удалось создать httpd.pid в каталоге «run». Это не имело смысла, потому что в этом каталоге был правильный контекст для чтения / записи «httpd_sys_rw_content_t» (который мне пришлось найти в «/ etc / selinux / target / context / customizable_types».
Я понял (после нескольких часов поиска), что в журнале ошибок он не дает вам полный путь, но когда apache помечает его chroot dir на «/ home / httpdjail».
В этой папке я нашел еще один каталог "run". После изменения разрешений на:
chcon -Rv -t httpd_sys_content_rw_t / home / httpdjail /
ЭТО СРАБОТАЛО!! ^^
Я предполагаю, что если вы дадите правильные разрешения своему "/ chroot / httpd", это решит вашу проблему.
Надеюсь на эту помощь!
Я не знаю о вашем недопустимом логическом значении, но вы можете найти проблемы с разрешением SELinux, проверив его журнал (попробуйте /var/log/audit/audit.log)
Я считаю, что журнал покажет контекст / тип, используемый httpd / apache, и любой файл, к которому SELinux запрещает доступ. Также попробуйте ls -lZ чтобы раскрыть контекст любого заданного файла, и прежде чем вы потеряетесь, пытаясь перенастроить разрешения SELinux, попробуйте restorecon -R -F -v (восстановить контекст).
В ответ на подробный отчет audit.log, да, это так! Однако, если вы ищете один конкретный файл для известного процесса, это не так уж и плохо. Пример Apache (httpd) не загружается / etc /хозяева является:
type=AVC msg=audit(1311546944.235:1040): avc: denied { read } for pid=1396 comm="httpd"
name="hosts" dev=dm-0 ino=262931
scontext=user_u:system_r:httpd_t:s0
tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file
Также стоит отметить, что мне приходилось выходить из строя без редактирования какой-либо конфигурации SELinux. например когда файлы загружаются через scp, при перемещении между каталогами и в приведенном выше примере я понятия не имею, но restorecon исправил это.
Вы можете выполнить поиск в audit.log по любому признаку httpd. Надеюсь это поможет.
Попробуй это:
# echo "httpd_disable_trans=1" > /etc/selinux/targeted/booleans
и перезапустите Apache, чтобы увидеть, что произойдет.
Если вы используете MTA, например postfix, вы можете сохранить настройки SElinux:
httpd_can_sendmail=1
По этой причине я предлагаю сделать следующее:
echo "httpd_disable_trans=1" >> /etc/selinux/targeted/modules/active/booleans.local