As variáveis de ambiente mostradas pelo comando SET podem ser notavelmente diferentes dependendo do nível de privilégio da sessão do prompt de comando. Além disso, parece que qualquer programa executado com credenciais administrativas pelo mesmo usuário pode criar variáveis de ambiente que persistirão por muito tempo após o término do processo e serão definidas em qualquer processo elevado subsequente iniciado por esse usuário (e SOMENTE nesses processos elevados). Não consegui encontrar essas variáveis na guia Ambiente mostrada pelo Process Explorer para nenhum processo associado à sessão de login do usuário. Minha pergunta é: onde esses valores estão armazenados e por que o Process Explorer não consegue acessá-los (é claro, como o Process Explorer é executado de forma elevada por padrão, essas variáveis aparecem em sua própria guia Ambiente)? Ou eu simplesmente os ignorei?
Responder1
De onde vêm as variáveis de ambiente para um processo cmd.exe elevado?
Como todos os processos, ele obtém seu ambiente do processo que gerou a instância do prompt de comando.
Quando um processo gera outro processo, o processo filho herda o ambiente do pai. Se o pai for privilegiado, provavelmente terá mais variáveis/diferentes do que se não fosse. Quando gera um processo filho, o filho obtém o mesmo conjunto para começar.
As variáveis de ambiente mostradas pelo comando SET podem ser notavelmente diferentes dependendo do nível de privilégio da sessão do prompt de comando.
Porque quando o Explorer não gera processos privilegiados, o CSRSS o faz. Ao executar um programa “como administrador”, você recebe um prompt do UAC que escurece a tela. Isso ocorre porque o CSRSS é um processo de sistema que lida com prompts do UAC e elevação de processos. Portanto, embora o Explorer e seus processos filhos tenham um ambiente, um prompt de comando elevado (que é gerado pelo processo do sistema de alto privilégioa mandodo Explorer) obtém um conjunto ligeiramente diferente com algumas variáveis extras/diferentes.
Além disso, parece que qualquer programa executado com credenciais administrativas pelo mesmo usuário pode criar variáveis de ambiente que persistirão por muito tempo após o término do processo e serão definidas em qualquer processo elevado subsequente iniciado por esse usuário (e SOMENTE nesses processos elevados).
Não. O setcomando é somente de sessão. Depois de fechar o prompt de comando, todas as alterações feitas serão perdidas. Para fazer alterações persistentes, você deve usar uma ferramenta externa, como um utilitário de terceiros ou o programa de ferramentas da Microsoft setx. Isso é verdade até mesmo para prompts de comando elevados; o setcomando simplesmente não possui funcionalidade para modificar o ambiente no registro.
Não consegui encontrar essas variáveis na guia Ambiente mostrada pelo Process Explorer para nenhum processo associado à sessão de login do usuário.
Porque quaisquer alterações que você fizer setsó serão visíveis emtão específicoprompt de comando e quaisquer processos que você inicia a partirEsse específicoprompt de comando; as alterações não se propagam para outros processos.
Minha pergunta é onde esses valores estão armazenados e por que o Process Explorer não consegue acessá-los (é claro, como o Process Explorer é executado de forma elevada por padrão, essas variáveis aparecem em sua própria guia Ambiente)? Ou eu simplesmente os ignorei?
As variáveis de sessão são armazenadas nesse ambiente específico do prompt de comando. O Process Explorer pode vê-los para aquela instância específica do cmd, mas eles não estarão em nenhum outro processo. Se você iniciar um programa a partir desse prompt de comando, poderá ver essas alterações no processo filho'Ambienteguia no Process Explorer porque ele os herdará desse prompt de comando.
Se você usar um programa como setxpara definir uma variável persistente, elas serão armazenadas no registro. Se você definir uma variável de nível de usuário (para o usuário atual), ela será armazenada em HKCU\Environment(ou HKU\<USER>\Environmentpara outros usuários). Se você definir uma variável no nível do sistema, ela será armazenada no arquivo HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.
Esteja ciente de que se você modificar manualmente o ambiente por meio do registro, apenas novos processos captarão as alterações. Para que o processo existente veja as alterações, você deve reiniciá-los ou transmitir uma WM_SETTINGCHANGEmensagem. (Ferramentas como setxtransmitir a mensagem para todas as janelas de nível superior.)
Responder2
Acho que a saída SETsó pode ser diferente quando você não está logado como membro do grupo Administrador. É por isso que é solicitado um usuário/senha. Nesse caso, você realmente faz login como administrador para esse processo.
Se você já é membro do grupo de administradores, a saída de SET é a mesma em ambos os casos para mim.
Portanto, se minha hipótese for verdadeira, as variáveis de privilégio elevado são definidas como Variáveis de Usuário para Administrador.
Responder3
Não está muito claro exatamente como as variáveis de ambiente são definidas em um processo elevado recém-criado, mas a maioria delas vem do conjunto existente do usuário atual (conforme mostrado pelo comando cmd.exe SET não elevado), bem como qualquer um que existem na chave de registro HKCU/Volatile Environment do usuário, que foram criadas desde o início da sessão de login atual (ou instância atual do Explorer?) e não são mostradas na lista SET não elevada. Existem algumas variáveis no meu Windows 10 que ocorrem na lista não elevada, mas não na lista elevada.
Esta questão foi motivada pelo comportamento de versões mais antigas do Macrium Reflect, que é discutido emhttps://forum.macrium.com/Topic752-1.aspxA versão atual desse programa agora cria essas variáveis problemáticas em HKU/.DEFAULT/Volatile Environment (AKA HKU/S-1-5-18/Volatile Environment) em vez de na chave HKCU.