Devo representar o PHP via FastCGI?

Question

Estou instalando a versão mais recente do PHP no IIS 7.5 via FastCGI, e todos as instruções dizem que o FastCGI deve representar o cliente chamador configurando

 fastcgi.impersonate = 1

Se meu site tiver essa configuração

• pool de aplicativos dedicado
• identidade do pool de aplicativos de ApplicationPoolIdentity
• somente autenticação anônima (como IUSR)

por que eu quero fingir?

Eu venho de um plano de fundo ASP.NET, onde o IUSR obtém permissões somente leitura e a identidade do pool de aplicativos obtém quaisquer permissões de gravação. Dar acesso de gravação ao IUSR geralmente abre as portas para vulnerabilidades do WebDAV. Então hesito em deixar o PHP rodar como IUSR.

Não consigo encontrar muitas pessoas a fazer esta pergunta ( 1 | 2 ) então acho que devo estar perdendo alguma coisa. Alguém pode esclarecer isso para mim?

    

Answer 1

13 meses depois, eu quis revisitar minha própria pergunta. Nesse período, transferi meia dúzia de sites do IIS 6 para o IIS 7.5 e os configurei com o meu método preferido. Tudo o que posso dizer é que os sites funcionam, eles não tiveram problemas de segurança (não que esses sites sejam populares) e, na minha opinião, a configuração é mais segura do que o recomendado pelo learn.iis.net.

Para a posteridade, aqui estão as configurações relevantes. No PHP INI:

cgi.force_redirect = 0
cgi.fix_pathinfo=1
fastcgi.impersonate = 0

No IIS:

• Pool de aplicativos > Identidade > ApplicationPoolIdentity
• Website > Autenticação > Autenticação anônima > Usuário específico: IUSR

As permissões do NTFS e onde aplicá-las:

• IUSR - Conceder leitura, negar gravação
  • O diretório raiz do site do IIS. Por exemplo, em um projeto do Zend Framework, este seria o diretório / public.
  • Se o seu aplicativo fizer o upload de arquivos e salvá-los em um diretório público, você precisará aplicar essa permissão ao diretório de upload temporário. Isso ocorre porque move_uploaded_file preservará as permissões do diretório de upload . Essa é a maior desvantagem dessa configuração de permissões que encontrei.
• ApplicationPoolIdentity ( IIS AppPool\<<YourApplicationPoolName>> ) - Conceder leitura & Lista
  • A raiz do seu aplicativo PHP. Por exemplo, em um projeto do Zend Framework, isso seria o projeto inteiro.
  • Qualquer biblioteca externa (Zend, Doctrine, etc.) incluída pelo seu aplicativo que não esteja na pasta do aplicativo.
• ApplicationPoolIdentity - Modificar concessão
  • Qualquer local em que seu aplicativo irá gravar, como upload_tmp_dir , session.save_path e error_log .
  • Às vezes, preciso adicionar essa permissão à raiz do aplicativo PHP no meu ambiente de desenvolvimento para oferecer suporte a coisas como Auto-geração de proxies do Doctrine .
• ApplicationPoolIdentity - Lista de subvenções
  • Se o seu aplicativo estiver em um diretório virtual, você precisará adicionar essa permissão à raiz do site. Isso permite que seu aplicativo leia seu web.config pai. Por exemplo, se a raiz do aplicativo for link , defina essa permissão no diretório da web example.com. Especificamente, você só precisa se inscrever em "Esta pasta e arquivos", "somente neste contêiner".

Espero que isso ajude qualquer outra pessoa que decida que as instruções do learn.iis.net não são ideais.

    

Answer 2

Veja: link

Impersonation and file system access

It is recommended to enable FastCGI impersonation in PHP when using IIS. This is controlled by the fastcgi.impersonate directive in php.ini file. When impersonation is enabled, PHP will perform all the file system operations on behalf of the user account that has been determinedby IIS authentication.

Por documentação, simplesmente permite que o fastcgi aja em nome do cliente usando todas as mesmas permissões (no seu caso, o que parece ser a conta IUSR). Em outras palavras, para executar todas as ações normalmente permitidas às próprias credenciais do cliente (ou anônimas). Nem mais nem menos. Sem esse conjunto, imagino que fastcgi pobres ficariam aleijados.