IIS AppPoolIdentity e permissões de acesso de gravação do sistema de arquivos

Aqui está um problema com o IIS 7.5 e o ASP.NET que eu tenho pesquisado e chegado a lugar nenhum. Qualquer ajuda seria muito apreciada.

Minha pergunta é: usando o ASP.NET no IIS 7.5, como o IIS e / ou o sistema operacional permitem que o aplicativo Web grave em uma pasta como C:\dumpquando executado sob confiança total? Como é que não preciso adicionar explicitamente o acesso de gravação para o usuário do pool de aplicativos (neste caso ApplicationPoolIdentity)?

Isso eu sei:

• No IIS 7.5, a identidade padrão para um pool de aplicativos é ApplicationPoolIdentity.
• ApplicationPoolIdentity representa uma conta de usuário do Windows chamada "IIS APPPOOL \ AppPoolName", criada quando o Pool de Aplicativos é criado, em que AppPoolName é o nome do Pool de Aplicativos.
• O usuário "IIS APPPOOL \ AppPoolName" é por padrão um membro do IIS_IUSRSgrupo.
• Se você estiver executando sob Full Trust, sua aplicação web pode escrever para muitas áreas do sistema de arquivos (excluindo pastas como C:\Users, C:\Windows, etc). Por exemplo, seu aplicativo terá acesso para gravar em algumas pastas, como C:\dump,.
• Por padrão, o IIS_IUSRSgrupo não recebe acesso de leitura ou gravação C:\dump(pelo menos, o acesso visível na guia "Segurança" no Windows Explorer).
• Se você negar o acesso de gravação IIS_IUSRS, receberá uma SecurityException ao tentar gravar na pasta (conforme o esperado).

Portanto, levando tudo isso em consideração, como o acesso de gravação é concedido ao usuário "IIS APPPOOL \ AppPoolName"? O processo w3wp.exe é executado como esse usuário. Portanto, o que permite que esse usuário grave em uma pasta à qual parece não ter acesso explícito?

Observe que eu entendo que isso provavelmente foi feito por uma questão de conveniência, pois seria difícil conceder ao usuário acesso a todas as pastas em que ele precisa gravar se você estiver executando no Full Trust. Se você deseja limitar esse acesso, sempre pode executar o aplicativo em Média Confiança. Estou interessado em descobrir como o sistema operacional e / ou o IIS permitem que essas gravações ocorram, mesmo que pareça não haver acesso explícito ao sistema de arquivos concedido.

A ApplicationPoolIdentityassociação é atribuída ao Usersgrupo, bem como ao IIS_IUSRSgrupo. À primeira vista, isso pode parecer um pouco preocupante, no entanto, o Usersgrupo possui direitos NTFS limitados.

Por exemplo, se você tentar criar uma pasta na C:\Windowspasta, verá que não pode. O ApplicationPoolIdentityainda precisa ser capaz de ler arquivos das pastas do sistema Windows (caso contrário, de que outra forma o processo do operador seria capaz de carregar dinamicamente DLLs essenciais).

No que diz respeito às suas observações sobre a possibilidade de gravar na sua c:\dumppasta. Se você der uma olhada nas permissões nas Configurações de segurança avançadas, verá o seguinte:

Veja que a permissão especial está sendo herdada de c:\:

Essa é a razão pela qual seu site ApplicationPoolIdentitypode ler e gravar nessa pasta. Esse direito está sendo herdado da c:\unidade.

Em um ambiente compartilhado em que você possivelmente tenha várias centenas de sites, cada um com seu próprio pool de aplicativos e identidade do pool de aplicativos, você armazenaria as pastas do site em uma pasta ou volume em que o Usersgrupo foi removido e as permissões definidas de forma que apenas os administradores A conta SYSTEM tem acesso (com herança).

Você atribuiria individualmente as permissões necessárias que cada uma IIS AppPool\[name]requer na pasta raiz do site.

Você também deve garantir que todas as pastas criadas nos locais onde você armazena arquivos ou dados potencialmente sensíveis tenham o Usersgrupo removido. Você também deve garantir que os aplicativos que você instala não armazenem dados confidenciais em suas c:\program files\[app name]pastas e que eles usem as pastas de perfil de usuário.

Portanto, sim, à primeira vista, parece que ele ApplicationPoolIdentitytem mais direitos do que deveria, mas na verdade não tem mais direitos do que os membros do grupo ditam.

A ApplicationPoolIdentityassociação ao grupo de um pode ser examinada usando a ferramenta SysInternals Process Explorer . Encontre o processo de trabalho que está sendo executado com a Identidade do Pool de Aplicativos em que você está interessado (você precisará adicionar a User Namecoluna à lista de colunas a ser exibida:

Por exemplo, eu tenho um pool aqui chamado 900300que possui uma identidade de pool de aplicativos IIS APPPOOL\900300. Clique com o botão direito do mouse nas propriedades do processo e selecione a guia Segurança que vemos:

Como podemos ver IIS APPPOOL\900300é um membro do Usersgrupo.

1. Clique com o botão direito na pasta.

2. Clique em Propriedades

3. Clique na guia Segurança. Você verá algo assim:

4. Clique no botão "Editar ..." na tela acima. Você verá algo assim:

5. Clique no botão "Adicionar ..." na tela acima. Você verá algo assim:

6. Clique no botão "Locais ..." na tela acima. Você verá algo assim. Agora, vá até o topo desta estrutura em árvore e selecione o nome do seu computador e clique em OK.

7. Agora digite "iis apppool \ your_apppool_name" e clique no botão "Verificar nomes". Se o pool de aplicativos existir, você verá o nome do pool de aplicativos na caixa de texto com sublinhado. Clique no botão OK.

8. Marque / desmarque qualquer acesso que você precise conceder à conta

9. Clique no botão Aplicar e depois em OK.

Cada pool de aplicativos no IIs cria sua própria pasta de usuário segura com permissão de leitura / gravação COMPLETA, por padrão, em c: \ users. Abra a pasta Usuários e veja quais pastas do pool de aplicativos estão lá, clique com o botão direito do mouse e verifique seus direitos para a conta virtual do pool de aplicativos atribuída. Você deve ver sua conta do pool de aplicativos já adicionada com acesso de leitura / gravação atribuído a sua raiz e subpastas.

Portanto, esse tipo de acesso ao armazenamento de arquivos é feito automaticamente e você deve poder escrever o que quiser nas pastas de contas de usuário dos pools de aplicativos sem alterar nada. É por isso que as contas de usuário virtual para cada pool de aplicativos foram criadas.

Tentei isso para corrigir problemas de acesso a um site do IIS, que se manifestava da seguinte maneira em Logs de Eventos → Windows → Aplicativo:

Nome do Log: Aplicativo
Fonte: ASP.NET 4.0.30319.0
Data: 1/5/2012 16:12:33 PM
ID do Evento: 1314
Categoria da tarefa: Evento da Web
Nível: Informações
Palavras-chave: Clássico
Usuário: N / D
Computador: SALTIIS01

Descrição:
Código do evento: 4008 
Mensagem do evento: A autorização do arquivo falhou para a solicitação. 
Hora do evento: 05/01/2012 16:12:33 
Hora do evento (UTC): 1/6/2012 12:12:33 
ID do Evento: 349fcb2ec3c24b16a862f6eb9b23dd6c 
Sequência de eventos: 7 
Ocorrência do evento: 3 
Código de detalhe do evento: 0 

Informações de aplicação: 
    Domínio do aplicativo: / LM / W3SVC / 2 / ROOT / Application / SNCDW-19-129702818025409890 
    Nível de confiança: Completo 
    Caminho virtual do aplicativo: / Application / SNCDW 
    Caminho do aplicativo: D: \ Sites \ WCF \ Application \ SNCDW \ 
    Nome da máquina: SALTIIS01 

Processo de informação: 
    ID do processo: 1896 
    Nome do processo: w3wp.exe 
    Nome da conta: iisservice 

Pedir informação: 
    URL da solicitação: http: //webservicestest/Application/SNCDW/PC.svc 
    Caminho da solicitação: /Application/SNCDW/PC.svc 
    Endereço do host do usuário: 10.60.16.79 
    Usuário: js3228 
    É autenticado: True 
    Tipo de autenticação: Negociar 
    Nome da conta do encadeamento: iisservice 

No final, tive que dar ao Everyonegrupo do Windows acesso de leitura a essa pasta para fazê-la funcionar corretamente.