Devo representar o PHP via FastCGI?

Estou instalando a versão mais recente do PHP no IIS 7.5 via FastCGI, e todas as instruções dizem que o FastCGI deve representar o cliente de chamada, definindo

 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 representar?

Eu venho de um plano de fundo do ASP.NET, onde o IUSR obtém permissões somente leitura e a identidade do pool de aplicativos obtém 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 funcionar como o IUSR.

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

13 meses depois, eu queria 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 sejam sites 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
• Site> Autenticação> Autenticação Anônima> Usuário Específico: IUSR

As permissões 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, esse seria o diretório / public.
  • Se seu aplicativo fizer upload de arquivos e salvá-los em um diretório público, você deverá aplicar esta permissão ao diretório de upload temporário. Isso ocorre porque move_uploaded_filepreservará as permissões do diretório de upload. Essa é a maior desvantagem dessa configuração de permissões que eu encontrei.
• ApplicationPoolIdentity ( IIS AppPool\<<YourApplicationPoolName>>) - Conceder leitura e lista
  • A raiz do seu aplicativo PHP. Por exemplo, em um projeto do Zend Framework, este seria o projeto inteiro.
  • Quaisquer bibliotecas externas (Zend, Doctrine etc.) incluídas pelo seu aplicativo que não estejam na pasta do aplicativo.
• ApplicationPoolIdentity - Grant Modify
  • Qualquer local onde a sua aplicação vai escrever tais 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 dar suporte a coisas como a geração automática de proxies do Doctrine .
• ApplicationPoolIdentity - Lista de Concessõ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 seu aplicativo é http://example.com/MyPHPApp , defina essa permissão no diretório da web example.com. Especificamente, você só precisa aplicar a "Esta pasta e arquivos", "Somente neste contêiner".

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

Consulte: http://www.php.net/manual/en/install.windows.iis6.php

Representação e acesso ao sistema de arquivos

É recomendável ativar a representação do FastCGI no PHP ao usar o IIS. Isso é controlado pela diretiva fastcgi.impersonate no arquivo php.ini. Quando a representação está ativada, o PHP executará todas as operações do sistema de arquivos em nome da conta do usuário que foi determinada pela autenticação do IIS.

Segundo a documentação, ele simplesmente permite que o fastcgi atue em nome do cliente usando todas as mesmas permissões (no seu caso, o que parece ser a conta IUSR). Em outras palavras, executar todas as ações normalmente permitidas nas credenciais do cliente (ou da sua). Nem mais nem menos. Sem esse conjunto, imagino que fastcgi pobre seja deixado aleijado.