Tenho PHP rodando como DSO. Como tal, meu script de instalação (que grava em um arquivo de configuração) não pode gravar.
Como dou ao Apache (usuário: ninguém) a capacidade de gravar no arquivo?
Responder1
Eu faria isso apenas em um servidor de desenvolvimento em um ambiente seguro. Muitas aplicações PHP irão gerar o arquivo na tela para que ele possa ser copiado com segurança para o diretório de configuração.
A maneira rápida (e insegura) de fazer isso é executar chmod 777 .
a partir do diretório onde o arquivo deve estar. Antes de fazer isso, execute ls -ld .
para obter as permissões para as quais você as definirá novamente. Em alguns casos, o diretório necessário não existirá, portanto será necessário criá-lo primeiro. Imediatamente após a gravação do arquivo de configuração, redefina o diretório para suas permissões originais. O comando correto é provavelmente chmod 755 .
executado chmod 750 .
a partir do diretório. Verifique com o comando ls.
Altere as permissões no arquivo de configuração para que o Apache não possa mais gravar nele ( chmod o-w configfile
). Os aplicativos geralmente vêm com arquivos de configuração de exemplo. Colocar um deles no diretório de configuração e editá-lo pode ser uma abordagem melhor. Isso requer que você aprenda e compreenda as opções de configuração. Você pode usar o script de configuração on-line para auxiliar em suas edições.
Responder2
Você pode gravar seus arquivos de configuração em um diretório temporário como /tmp/config/
. Em seguida, você pode executar um script de shell para copiar os arquivos de configuração para /tmp/config/
o local desejado.
Para conceder as permissões necessárias, você pode adicionar o usuário nobody
ao arquivo sudoers. A entrada deve ser semelhante a:
nobody ALL=NOPASSWD: /path/to/your_script.sh
O script de shell (não se esqueça de adicionar permissão de execução).
cp -r /tmp/config/* /desired/path/to/config
Em PHP, você precisa de um pequeno trecho de código como:
<?php
$output = shell_exec('sudo /path/to/your_script.sh');
echo "$output";
?>
Responder3
Em um ambiente compartilhado tudo fica um pouco complicado quando se trata de questões de segurança. Ao alterar a propriedade do arquivo para 'ninguém' você dá ao Apache acesso de gravação a esse arquivo, mas, se o módulo PHP não tiver configurações para restringir cada host virtual a seu próprio diretório, ele também daria acesso a outros. Verifique como ele está configurado em seu ambiente.
O Apache geralmente é executado como usuário 'nobody' e grupo 'nobody', então você também pode brincar com permissões de grupo. Altere o grupo do arquivo para ‘nobody’ e defina a permissão para 664.
Se você não puder alterar o proprietário ou grupo do arquivo, o FTP geralmente permitirá alterar as permissões. Supondo que o Apache não seja um dos usuários/grupos que possui esse arquivo, você terá que configurá-lo para 777, o que é muito inseguro, mas tudo depende do tipo de ambiente em que você está. , instale seu aplicativo e altere-o novamente para 644 ou 444 (somente leitura).
Responder4
Este é o problema típico ao executar PHP como DSO com cPanel, mas também se aplica a outras configurações.
Ao executar este método, os processos PHP são gerenciados pelo usuário que está executando o httpd. Na maioria dos casos, esse usuário é o usuário 'ninguém'. Isso significa que quando o PHP interage com arquivos no sistema de arquivos, eles devem estar acessíveis ao usuário 'ninguém'. Isso cria problemas de permissão, pois seu usuário normal baseado em cPanel não terá acesso a arquivos RW (leitura/gravação) que pertencem ao usuário 'ninguém' sem as alterações corretas de permissão. A maioria dos aplicativos/scripts da web PHP precisam gravar em arquivos e diretórios e, se forem de propriedade do usuário cPanel, sem alterar as permissões nos arquivos/diretórios para 777, isso causará problemas e, em alguns casos, danificará seu(s) site(s) .
Portanto, neste caso você pode apenas gerenciar as permissões manualmente, configurando-as para 777
Ao executar este método PHP, você terá que gerenciar manualmente as permissões por usuário para garantir que seus aplicativos/scripts PHP possam ler e gravar nos arquivos e diretórios dos quais precisam funcionar.
Ou, melhor, se você puder mudar para Mod_SuPHP e não tiver problemas de desempenho (já que o DSO é muito mais rápido), você poderá executar o PHP como o usuário que executa o cPanel.
Se ignorarmos os problemas de permissão que podem ser encontrados ao executar o PHP por meio do DSO, há alguns benefícios nisso, quando comparado ao SuPHP. A primeira é a velocidade. Mod_PHP é mais rápido que Mod_SuPHP. Isso se deve principalmente ao fato de que toda solicitação processada pelo Mod_SuPHP é empacotada para ser executada como o usuário proprietário dos arquivos. Isso pode não ser muito perceptível em sites de menor tráfego, mas em sites de maior tráfego pode aumentar muito rapidamente. A segunda é a funcionalidade completa com adições de cache de optcode PHP, como eAcclerator, APC e Xcache. Para obter todos os benefícios de um cache optcode PHP, você precisa de um usuário compartilhado que é usado ao armazenar em cache o código de bytes PHP compilado e executar o PHP por meio de um DSO executa o PHP, pois o usuário 'ninguém' atende a essa necessidade. Você pode saber se o seu servidor está configurado para executar PHP através de um DSO acessando o WHM e procurando em Main >> Service Configuration >> Apache Configuration . >> Configuração PHP e SuExec
Aqui você pode encontrar mais detalhes:
https://helpdesk.wiredtree.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=1663