Tornar o Apache capaz de escrever em arquivos PHP com o PHP rodando como DSO?

Question

Eu tenho o PHP rodando como um DSO. Assim, meu script de instalação (que grava em um arquivo de configuração) não pode escrever.

Como faço para dar ao apache (usuário: nobody) a capacidade de gravar no arquivo?

    

Answer 1

Eu só faria isso em um servidor de desenvolvimento em um ambiente seguro. Muitos aplicativos PHP geram 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 . do diretório onde o arquivo deve ir. Antes de executar isso, execute ls -ld . para obter as permissões para as quais você as devolverá. Em alguns casos, o diretório requerido não existirá, então você precisará criá-lo primeiro. Imediatamente após a gravação do arquivo de configuração, redefina o diretório para as permissões originais. O comando correto provavelmente é chmod 755 . ou chmod 750 . executado no 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 desses no diretório de configuração e edição pode ser uma abordagem melhor. Isso requer que você aprenda e entenda as opções de configuração. Você pode usar o script de configuração on-line para ajudar nas suas edições.

    

Answer 2

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 de /tmp/config/ para o local desejado.

Para conceder as permissões necessárias, você pode adicionar o usuário nobody ao arquivo sudoers. A entrada deve se parecer com:

nobody   ALL=NOPASSWD: /path/to/your_script.sh

O script de shell (não esqueça de adicionar permissão de execução).

cp -r /tmp/config/* /desired/path/to/config

No PHP, você precisa de um pequeno trecho de código como:

<?php
$output = shell_exec('sudo /path/to/your_script.sh');
echo "$output";
?>

    

Answer 3

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 'nobody', você concede ao Apache acesso de gravação a esse arquivo, mas, se o módulo PHP não tiver configurações para restringir cada virtualhost a cada diretório próprio, ele também fornecerá acesso a outros. Verifique como está configurado no seu ambiente.

O Apache geralmente é executado como usuário 'nobody' e o grupo 'nobody', portanto você também pode usar 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 o grupo do arquivo, o FTP geralmente permite alterar as permissões. Supondo que o Apache não seja do usuário / grupo que possui esse arquivo, você teria que configurá-lo para 777, o que é muito inseguro, mas tudo depende do tipo de ambiente em que você está. Talvez você possa configurá-lo temporariamente , instale seu aplicativo e mude-o para 644 ou 444 (somente leitura).

    

Answer 4

Este é o problema típico que executa o PHP como um DSO com o cPanel, mas também se aplica a outras configurações.

When running this method, PHP processes are handled by the user that is running httpd. In most cases, this user is the 'nobody' user. This means when PHP interacts with files on the file system, they have to be accessible by the 'nobody' user. This creates permissions issues as your normal cPanel based user will not have access to RW (read/write) files that are owned by the 'nobody' user without the correct permissions changes. Most PHP web apps/scripts need to write to files and directories and if they are owned by the cPanel user, without changing the permissions on the files/directories to 777, it will cause issues and in some cases, break your website(s).

Portanto, neste caso, você pode apenas e gerenciar apenas as permissões manualmente, definindo-as como 777

When running this PHP method you will have to manually manage the permissions on a per user basis to ensure that your PHP apps/scripts can read and write to the files and directories of which it needs to function.

Ou, melhor, se você pode mudar para o Mod_SuPHP e você não tem problemas de desempenho (como o DSO é muito mais rápido), você será capaz de rodar o PHP como o usuário rodando o cPanel.

If we overlook the permissions issues that one can run into with running PHP through DSO, there are some some benefits to it, when compared to SuPHP. The first is speed. Mod_PHP is faster than Mod_SuPHP. This is mainly due to the fact that every request that is processed by Mod_SuPHP is wrapped to run as the user that owns the files. This might not be very noticeable on lower traffic sites, but on higher traffic sites, it can add up pretty quick. The second is full functionality with PHP optcode caching additions such as eAcclerator, APC and Xcache. To net the full benefit of a PHP optcode cache, you need a shared user which is used when caching the compiled PHP byte code and running PHP via a DSO runs PHP as the 'nobody' user fills this need. You can tell if your server is setup to run PHP through a DSO by going to the WHM and looking under Main >> Service Configuration >> Apache Configuration . >> PHP and SuExec Configuration

Aqui você pode encontrar mais detalhes:

link