IUSR vs snag de permissão ADMINISTRATOR

2

Uma aplicação lançada pelo IIS6 (como resultado de uma solicitação HTTP) está falhando ao inicializar uma dll. Se eu iniciar como administrador quando estiver logado localmente clicando duas vezes, tudo ficará bem.

Este aplicativo utiliza criptografia TLS através de uma DLL de terceiros chamada cryptlib. link Isso não deve ser grande coisa em si, como a maioria dos meus aplicativos CGI usam o MySQL / zlib / ... etc dlls sem problema. Nesse caso (provavelmente devido à natureza da criação de uma sessão SSL / TLS), o aplicativo é executado corretamente se iniciado clicando duas vezes como administrador, mas não será executado quando for iniciado pelo IIS como resultado de uma solicitação recebida. O IIS usa a conta "Conta de convidado da Internet ... (... IUSR)" (supomos) para executar o aplicativo CGI a partir de uma solicitação HTTP POST de página da Web simples.

Eu tentei dar controle total à conta IUSR no aplicativo, na dll e na pasta, mas sem alegria. Em seguida, iniciei o ProcMon e procurei um resultado "ACCESS DENIED". O único que consegui encontrar foi o resultado de CreateFile Acesso Desejado: Ler Atributos, Excluir, Sincronizar, Disposição: Abrir, Opções: Não-Alerta Synchronous IO, C: \ WINDOWS \ Debug \ UserMode \ ChkAcc.log

Isso é intrigante, pois meu aplicativo não está gravando nesse arquivo de log (presumo que o IIS seja assim, por que ele estaria com problemas?)

Em seguida, comparei a saída ProcMon para o lançamento bem-sucedido do Administrador contra o lançamento IUSR e descobri que uma operação "ReadFile" não estava presente na inicialização com falha. Eu não recebo um erro ACCESS DENIED para isso, a operação simplesmente não acontece.

A sequência de operações sequenciais para o cl32.dll deve ser: QueryOpen CreateFile CreateFileMapping QueryStandardInformationFile CreateFileMapping CreateFileMapping CloseFile Carregar Imagem ReadFile

Eu assumo que este é o lugar onde a DLL é carregada na memória para uso.

Em vez da operação ReadFile (no lançamento com falha), há: RegOpenKey HKU \ S-1-5-21-4122272316-1273673783-4216733774-1003 NOME NÃO ENCONTRADO

Ele soou um pouco como o problema de "Ignorar a verificação completa" descrito aqui link link mas isso não resolveu o problema.

Neste ponto, excedemos o limite de meu conhecimento de contas de usuário e permissões por uma grande margem. Uma coisa é clara, isso é um problema de permissões. A questão é, qual permissão?

ADICIONADO

Adicionando o ISUR aos administradores:  1. Clique com o botão direito do mouse em Meu computador na área de trabalho e clique em Gerenciar.  2. Quando a janela Gerenciamento do Computador for aberta, expanda Usuários e Grupos Locais.  3. Selecione Grupos e clique duas vezes em Administradores no painel direito.  4. Clique no botão Adicionar  5. Clique em Avançado, em Localizar agora e selecione IUSR  Clique em OK.  7. Reinicie o IIS

Isso NÃO resolveu o problema. Eu desenterrei o Filemon v7.3 e é IUSR que é

er.exe:2240 OPEN C:\WINDOWS\system32\USERENV.dll SUCCESS Options: Open Access: 00100021  
er.exe:2240 CLOSE C:\WINDOWS\system32\USERENV.dll SUCCESS  
er.exe:2240 OPEN C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER  
er.exe:2240 CREATE C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER 

Neste ponto, eu levo qualquer facada no escuro e com que permissão isso pode ser:)

ADICIONADO

Alterei a permissão no arquivo ChkAcc.log e na pasta UserMode, também verifiquei as permissões avançadas e encontrei uma negação no aplicativo e na DLL. Eu removi os dois. Eu reiniciei o IIS e até reiniciei a máquina. Ainda sem sorte.

Eu estou querendo saber se o ACESSO NEGADO é de fato o problema. Eu reescrevi o aplicativo para criar e gravar em um arquivo nessa pasta e funcionou:

OPEN            C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Options: OpenIf  Access: 00120196
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 0
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 0
WRITE           C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Offset: 0 Length: 41
WRITE           C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Offset: 41 Length: 2
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 43
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 43
CLOSE           C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS 

Isso me leva a suspeitar que a permissão da pasta não é o problema, mas a DLL não está inicializando por algum motivo.

Existe alguma maneira de dar ao IUSR permissões idênticas como ADMIN? então talvez eu possa removê-los um por um. Talvez eu possa até mesmo criar um segundo usuário com permissões ADMIN e o IIS usar isso em vez de IUSR para solicitações CGI de entrada?

A adição clara de IUSR ao grupo ADMIN não é o mesmo que executar o aplicativo como ADMIN.

ADICIONADO

Na verdade, o problema acabou por ser devido a dll realizar vários testes de verificação de sanidade na inicialização, incluindo a capacidade de ler arquivos. Para fazer isso, ele tenta ler o diretório pessoal do usuário (ou, no Windows, o diretório de perfil do usuário)

Na caixa de testes no Windows 2003 Server, eu acho

IUSR

CSIDL_APPDATA = C: \ WINDOWS \ system32 \ config \ systemprofile \ Dados de aplicativos

Administrador

CSIDL_APPDATA = C: \ Documents and Settings \ Administrator.MY-SERVER \ Dados de aplicativos

Eu suspeito que o processo cgi está sendo negado o acesso a quaisquer pastas system32. Esse é o comportamento que eu esperaria até que a IUSR fosse adicionada aos administradores, então eu esperaria que isso funcionasse ... mas isso não acontece. A solução foi reescrever a dll, mas ainda estou intrigado com isso

    
por Mike Trader 07.01.2010 / 10:02

1 resposta

2

Observe as duas linhas que você tem:

er.exe:2240 OPEN C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER  
er.exe:2240 CREATE C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER 

A primeira linha pode ser a aplicação verificando se ela existe, enquanto a segunda linha cria uma situação de "criar arquivo se ele não existir". As coisas que eu procuraria é que a conta IUSR não faz parte do grupo "USERS", mas é parte de "PESSOAS", e geralmente os hóspedes têm ainda menos privilégios do que "USERS". Você pode querer garantir que a conta IUSR tenha a capacidade de percorrer as pastas acima dela. Tente dar à conta IUSR acesso explícito para percorrer as pastas e a permissão na pasta "UserMode" para "Criar arquivos" (mas "SOMENTE PASTA").

Por fim, talvez haja permissões explícitas de "negação" para convidados que possam impedi-lo de acessar as pastas. Essas são as coisas que eu verificaria.

    
por 08.01.2010 / 05:45