Apache, suexec, PHP, suPHP

Question

Embora eu seja bem confortável como usuário do Linux , meu Linux Admin-fu é um pouco fraco. Assim, estou aqui procurando orientação com um servidor do CentOS que estou prestes a construir.

Eu preciso configurar um servidor web Apache2 para alguns de nossos clientes. Eu quero que o conteúdo da Web de cada cliente esteja em seu diretório pessoal ( USERDIR no apache.conf, certo?) Para os sites HTML estáticos. Eu quero que o Apache seja executado como o cliente ( suexec ?). Algumas de suas coisas serão aplicativos PHP e estou com a impressão de que também vou querer ver suphp .

Então, basicamente, quero parecer uma pequena versão de uma empresa de hospedagem compartilhada. Considerando o quão comum os são, acho que encontraria facilmente um bom guia de instruções sobre como configurar tudo isso, mas até agora tive pouca sorte. Eu suspeito que minhas palavras de pesquisa estão desativadas.

Então, as perguntas (fique à vontade para responder qualquer ou todos):

1. Alguém tem alguns links sólidos para guias atuais / modernos que me ajudariam a definir tudo isso? Não, o site de documentação do apache não é um guia; -)
2. Como tenho uma mistura de sites estáticos e aplicativos PHP, quero / preciso tanto do suexec quanto suphp instalado? Em caso afirmativo, isso apresenta algum desafio que eu deveria estar ciente?
3. Devo procurar outras opções em vez de suexec e suphp?

Eu pretendo dar aos usuários finais SSH, SFTP ou SCP acesso às suas coisas (se isso afetar alguma coisa).

Agradecemos antecipadamente por sua ajuda.

[Editar] Eu deveria ter mencionado isso antes: um dos principais objetivos da minha busca para emular um provedor de hospedagem compartilhada relacionado a perms e propriedade de arquivos. Eu realmente gostaria de ter que evitar ensinar os usuários sobre a necessidade de alterar essas coisas apenas para ver suas adições / alterações.

    

Answer 1

O uso de suexec e suphp impõe um tipo diferente de separação de privilégios que o padrão.

O padrão é separar a permissão do usuário do servidor da web. Ou seja, o usuário é o proprietário dos arquivos e ele precisa conceder ao servidor da Web permissão para visualizá-los e alterá-los.

O modelo suexec / suphp é que o servidor da Web (ao executar scripts) é executado na conta do usuário, portanto, o site tem permissão para fazer qualquer coisa que o usuário tenha permissão para fazer. Até certo ponto, isso remove a separação entre o usuário e o servidor, mas em troca impõe uma separação DIFERENTE: isto é, entre o site de um usuário e o site de um usuário diferente na mesma caixa.

Por padrão, o PHP sempre roda sob a conta de usuário do Apache, então os scripts PHP de um site podem acessar quaisquer arquivos que os scripts PHP de outro site possam. Portanto, se uma conta no servidor for invadida, a infecção poderá se espalhar para as outras. SuPHP impede isso.

Nem o suexec nem o suphp afetarão o modo como o apache exibe conteúdo estático . Todas as regras antigas ainda se aplicam. Em vez disso, suexec e suphp mudam a conta sob a qual o CGI e o PHP (respectivamente) serão executados. O Suexec faz com que o executável CGI seja executado sob a conta do proprietário, enquanto o SuPHP faz com que os scripts PHP sejam executados sob a conta do proprietário.

Suexec e SuPHP não são necessariamente melhores . Eles são apenas diferentes . Eles não impedirão que um site seja hackeado (e possivelmente tornarão o site mais fácil para hackear), mas impedirão que um comprometimento em um site se espalhe para todos os outros. Para o administrador do site, esse isolamento é sem dúvida mais importante, e é por isso que alguns sistemas de hospedagem compartilhada tornam o suexec e sufiram o padrão.

Uma "pegadinha" extremamente comum é que o SuPHP verifica a propriedade e as permissões de um script antes de ser executado e retornará um erro 500 se as permissões não forem apropriadas.

Em particular:

• O proprietário e o grupo do arquivo devem corresponder ao proprietário do website (conforme definido na configuração do apache)
• O arquivo não deve ser mundialmente gravável
• O diretório pai não deve ser mundialmente gravável