Sim, ele é executado com privilégios elevados.
Teste simples:
Você pode testar isso facilmente, abrindo um prompt de comando elevado e um não elevado. Execute o comando notepad.exe
nos dois e tente salvar um arquivo de texto em branco em C:\Windows
. Um salvará, um lançará um erro de permissão.
Teste completo:
Se isso não for suficiente para confirmar isso para você (realmente não me satisfez), você pode usar o AccessChk da SysInternals. Você precisará executar isso em um prompt de comando elevado.
Vamos começar verificando os dois processos do Bloco de Notas em execução:
Bloco de notas: ( accesschk.exe -v -p notepad
)
[11140] notepad.exe
Medium Mandatory Level [No-Write-Up, No-Read-Up]
RW DOMAIN\Tannerf
PROCESS_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
PROCESS_ALL_ACCESS
[11004] notepad.exe
High Mandatory Level [No-Write-Up, No-Read-Up]
RW BUILTIN\Administrators
PROCESS_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
PROCESS_ALL_ACCESS
Um está sendo executado sob o nome de usuário do meu domínio, o outro está sendo executado no grupo interno Administradores. Também possui um alto nível obrigatório . Você também pode executar com o -f
sinalizador para obter uma discriminação dos privilégios e tokens.
Arquivos MSIExec e MSI
Eu pensei que as coisas poderiam ficar um pouco mais complicadas ao executar msiexec
. Eu tenho um instalador independente do Google Chrome que foi útil para testar.
msiexec.exe iniciando o instalador do Chrome a partir do prompt elevado:
D:\Users\tannerf>accesschk.exe -p msiexec.exe
[10540] msiexec.exe
RW BUILTIN\Administrators
RW NT AUTHORITY\SYSTEM
chrome_installer.exe gerado pelo MSI:
D:\Users\tannerf>accesschk.exe -p chrome_installer.exe
[5552] chrome_installer.exe
NT AUTHORITY\SYSTEM
OWNER RIGHTS
RW NT SERVICE\msiserver
Não é mais tão cortado e seco! Parece que um chrome_installer.exe
processo foi executado através do serviço MSIServer.
Isso me faz pensar em qual comportamento outros instaladores podem ter, então eu executei um Evernote.msi que eu tinha à mão:
Msiexec.exe elevado iniciando um instalador do Evernote:
[6916] msiexec.exe
High Mandatory Level [No-Write-Up, No-Read-Up]
RW BUILTIN\Administrators
PROCESS_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
PROCESS_ALL_ACCESS
[4652] msiexec.exe
System Mandatory Level [No-Write-Up, No-Read-Up]
R BUILTIN\Administrators
PROCESS_QUERY_INFORMATION
PROCESS_QUERY_LIMITED_INFORMATION
Interessante; há um msiexec.exe que é executado no nível do sistema neste momento. Usei o Process Monitor para descobrir que a janela de instalação real exibida é proveniente do processo msiexec no nível do sistema. Matar o alto nível obrigatório também matou o processo no nível do sistema.
Msiexec.exe não elevado, iniciando um instalador do Evernote:
[7472] msiexec.exe
Medium Mandatory Level [No-Write-Up, No-Read-Up]
RW DOMAIN\Tannerf
PROCESS_ALL_ACCESS
RW NT AUTHORITY\SYSTEM
PROCESS_ALL_ACCESS
[4404] msiexec.exe
System Mandatory Level [No-Write-Up, No-Read-Up]
R BUILTIN\Administrators
PROCESS_QUERY_INFORMATION
PROCESS_QUERY_LIMITED_INFORMATION
Parece que o Evernote terá acesso no nível do sistema de qualquer maneira. Clicar duas vezes no instalador tem o mesmo resultado.
Conclusão:
Eu acho que está muito bem demonstrado que um processo herdará permissões, a menos que especificado de outra forma. Isso não garante que msiexec SomeProgram.msi
será executado com um alto nível obrigatório em todos os processos de processos; pode ser executado no nível do sistema ou no MSIServer. Sua milhagem pode variar, e eu não ficaria surpreso ao ver muitos casos em que essas regras parecem estar "quebradas".