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