Permissão negada: não foi possível criar /var/run/httpd.pid no Apache

Question

Estou trabalhando na configuração de um servidor web executando RedHat Enterprise 6 com Apache e PHP dentro de um ambiente chroot jail. O diretório chroot para o apache é / chroot / httpd. Eu segui este exemplo ainda quando vou iniciar o apache, Eu vejo o seguinte em / 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

Além disso, o SELinux está ativado e, de acordo com as instruções, você deve alterar o valor do booleano httpd_disable_trans para 1 usando o comando

setsebool httpd_disable_trans 1

No entanto, não consigo encontrar um booleano como esse em / selinux / booleans ou em qualquer parte do sistema. O comando produz o seguinte erro:

Could not change active booleans: Invalid boolean

Eu pesquisei na web por que esse booleano não está presente no sistema sem resultado. Eu não tenho idéia se é o SELinux que não está permitindo que o httpd seja iniciado ou se é um problema de permissões. Eu verifiquei duas vezes as permissões e elas parecem boas. Alguma sugestão?

Obrigado.

Atualização: Eu determinei que o SELinux é realmente o motivo desses erros. Alterar a política padrão de Impingir para Permissivo permite que o apache seja iniciado corretamente. A questão é, por que o httpd_disable_trans não está disponível no sistema? Isso me permitiria manter a segurança do SELinux junto com o apache.

Além disso, em uma nota lateral, com o apache dentro de um ambiente chroot, é melhor hospedar o conteúdo da web dentro do / chroot ou criar links simbólicos de lá para onde ele está localizado? Meu objetivo é que eu preciso ativar o conteúdo da web dentro de diretórios de usuários armazenados em / users.

Atualização 2: Algumas linhas de configuração do Apache que acredito serem relevantes:

.....
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
....

    

Answer 1

Acabei de descobrir qual problema. Este é o nosso ambiente:

RedHat 5 com o mais recente RPM do apache

Quando você olha para os registros de erros, ele se queixa de não conseguir criar o httpd.pid, sob o diretório "run". Não fazia sentido porque o diretório tinha o contexto correto para leitura / gravação "httpd_sys_rw_content_t" (que eu tinha que encontrar em "/ etc / selinux / targeted / contextts / customizable_types".

Eu percebi (depois de horas de busca) que no log de erros ele não te da o caminho completo, mas quando o apache faz o chroot dir para "/ home / httpdjail".

Sob essa pasta, encontrei outro diretório "run". Depois de alterar as permissões para:

chcon -Rv -t httpd_sys_content_rw_t / home / httpdjail /

TRABALHOU !! ^^

Suponho que, se você der as permissões corretas para o seu "/ chroot / httpd", isso corrigirá seu problema.

Espero que esta ajuda!

    

Answer 2

Eu não sei sobre o seu booleano inválido, mas você pode encontrar problemas de permissão do SELinux verificando seu log (tente /var/log/audit/audit.log )

Eu acredito que o log irá mostrar o contexto / tipo usado pelo httpd / apache e qualquer arquivo que o SELinux nega acesso. Tente também ls -lZ para revelar o contexto de qualquer arquivo e antes de você se perder tentando reconfigurar as permissões do SELinux, tente restorecon -R -F -v (contexto de restauração).

Em resposta ao audit.log sendo detalhado, sim, é! No entanto, se você estiver procurando por um arquivo específico para um processo conhecido, não é tão ruim. Um exemplo de Apache ( link ) que não está carregando / etc / hosts é:

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

Também vale a pena notar que experimentei contextos saindo do wack sem editar qualquer configuração do SELinux. por exemplo. quando os arquivos são enviados via scp, quando se deslocam entre diretórios e no exemplo acima, não tenho idéia, mas restorecon reparado.

Você pode procurar o audit.log em busca de qualquer sinal de 'httpd'. Espero que isso ajude.

    

Answer 3

Tente isto:

# echo "httpd_disable_trans=1" > /etc/selinux/targeted/booleans

e reinicie o Apache para ver o que acontece.

    

Answer 4

Se você estiver usando o MTA, por exemplo, postfix, talvez queira manter sua configuração do SElinux:

httpd_can_sendmail=1

Por esse motivo, ofereço isso:

echo "httpd_disable_trans=1" >> /etc/selinux/targeted/modules/active/booleans.local