Terminal: [Pergunta] Configurando o perfil do Windows Terminal para sempre iniciar elevado

Não há. Não acho que planejamos oferecer suporte a guias elevadas e não elevadas mistas, porque é uma falha de segurança.

Sim, eu sei que sudo é uma coisa, mas tivemos muitas discussões com a equipe de segurança sobre a criação de um sudo para Windows. O principal problema é devido ao fato de que qualquer processo não elevado pode enviar pressionamentos de tecla para qualquer outra janela não elevada.

Se você tivesse uma linha de comando elevada em execução em uma janela não elevada, um agente mal-intencionado não confiável poderia executar um ataque de elevação de privilégio direcionando as janelas não elevadas que estão executando a linha de comando elevada.

(como uma questão de vincular tópicos relacionados, #146)

EDITAR (14 de fevereiro de 2020)
Ok, então este comentário não envelheceu super bem. Originalmente, não havia _nenhum_ plano para dar suporte a isso, já que não funcionaria com o único HWND que tínhamos. Estamos trabalhando no projeto de uma solução que _pode_ suportar isso no futuro, mas não podemos nos comprometer com nada até termos certeza de que podemos encontrar uma solução apropriadamente segura, que garanta que um processo com privilégios inferiores não possa conduzir um terminal de privilégio mais alto.

Parece razoável. Acho que ter algo como uma combinação de #576 (Abrir como Admin na lista de atalhos) e talvez algum tipo de tecla de atalho para iniciar uma sessão de Admin do Terminal resolveria a maior parte da minha dor aqui.

Que tal ter um Terminal padrão e elevado aberto em uma única janela, mas em abas separadas?

@mdtauk acho que infelizmente se enquadra na mesma categoria. Como todas as guias estão sob o mesmo HWND, o HWND raiz é o que precisaria ser elevado para impedir que aplicativos não elevados direcionassem a janela.

Do ponto de vista da segurança (ignorando o design do Windows Terminal, HWND de raiz única etc.), quão "menos seguro" é o Terminal executando guias de elevação mista em comparação com a execução, digamos, de uma instância elevada do PowerShell ao lado de uma não elevada no UX atual ? O fato de os aplicativos do console estarem hospedados nas guias do Terminal não faz diferença para mim ...

Em uma nota semelhante: como ter uma janela não elevada é mais seguro, mesmo se eu abrir uma sessão PS remota onde agora posso ter privilégios de administrador em um servidor remoto que um não elevado pode dirigir agora. Para mim, isso parece muito pior do que obter acesso de administrador local, então não acho que executar uma guia como administrador seja diferente de remoting / ssh-ing em outros servidores. Em ambos os casos, preciso me sentir confortável o suficiente com meu sistema para fazer isso. É uma coisa de "tenho idade suficiente e entendo os riscos".

Sempre que tento executar o aplicativo Terminal com uma conta de administrador, clique com o botão direito -> executar como administrador, o UAC aparece duas vezes e ocorre um erro dizendo:
"O Windows não pode encontrar (path\WindowsTerminal.exe) Certifique-se de ter digitado ...".

O caminho existe e o aplicativo funciona corretamente para o usuário não administrador que criou o aplicativo, mas o outro usuário administrador não consegue executá-lo.
Se eu fizer login no usuário admin, o aplicativo do terminal não estará presente nas configurações ou no menu iniciar, como se nunca tivesse sido instalado no sistema.

Existe uma maneira de criar o aplicativo para que ele seja instalado para todos os usuários? Ou a raiz do projeto precisa estar em um diretório não específico do usuário?

@

Sempre que tento executar o aplicativo Terminal com uma conta de administrador, clique com o botão direito -> executar como administrador, o UAC aparece duas vezes e ocorre um erro dizendo:
"O Windows não pode encontrar (path\WindowsTerminal.exe) Certifique-se de ter digitado ...".

O caminho existe e o aplicativo funciona corretamente para o usuário não administrador que criou o aplicativo, mas o outro usuário administrador não consegue executá-lo.
Se eu fizer login no usuário admin, o aplicativo do terminal não estará presente nas configurações ou no menu iniciar, como se nunca tivesse sido instalado no sistema.

Existe uma maneira de criar o aplicativo para que ele seja instalado para todos os usuários? Ou a raiz do projeto precisa estar em um diretório não específico do usuário?

Estou vendo o mesmo problema acontecendo também.

Versão do Windows 18922.1000

Certo, então a execução de aplicativos da loja como administrador ou usuário diferente não está funcionando (por design, BTW). Muitos de nós estão logados (no PC) como uma conta normal não elevada. Executamos o powershell/cmd/etc como administrador para realizar determinadas tarefas.

Se a escolha final é implantar este aplicativo na loja do Windows, é inútil para mim sem alguma forma de abrir abas elevadas. Meus 2 centavos.

"Useless" talvez seja um pouco duro, mas, na verdade, precisamos de uma maneira de usar o novo terminal para aplicativos / shells de console não elevados e elevados. E para mim, o melhor UX seria oferecer suporte a uma combinação de guias elevadas e não elevadas na mesma instância do Windows Terminal. Menos preferível: suporte zero a muitas (normalmente uma) instâncias elevadas (cada uma com uma a muitas guias) ao lado de zero a muitas (normalmente uma) instâncias não elevadas.

O ConEmu é capaz de misturar abas elevadas e não elevadas na mesma janela. Algo assim não pode ser feito aqui?

Poderíamos ter um Terminal elevado lançando guias não elevadas? Ainda preciso iniciar elevado, MAS posso abrir uma nova guia "protegida".

Se quisermos ser muito específicos do Windows e ignorar outras plataformas que podem eventualmente ver o Terminal, talvez o uso de contêineres do Windows ou processos virtualizados possa ajudar nesse ponto problemático para alguns. Pessoalmente, estou bem com a solução atual, mas fazer com que os aplicativos de console sejam executados como processos isolados por padrão não seria uma má ideia do ponto de vista da segurança.

A elevação mista em uma janela é uma obrigação, pelo menos para mim.
Poderia ser um recurso opcional para ser alternado nas configurações?

@pratnala Com o ConEmu, apenas _parece_ que está fazendo isso, mas não está realmente fazendo isso. As "guias" elevadas e não elevadas são apenas visualizações em duas janelas/processos raiz completamente separados e isolados. Ele faz isso raspando o conteúdo das janelas entre outras coisas e auxiliares de elevação de proxy/broker etc. Claro, é tecnicamente possível, mas o que o ConEmu faz é meio inseguro. Uma coisa é um programa de terceiros fazer isso e fazer com que as pessoas optem pelo risco baixando o ConEmu, mas outra é a Microsoft endossar oficialmente isso fazendo isso por conta própria. Se eu quiser esconder minhas chaves da porta da frente sob o capacho, tudo bem - esse é o meu risco idiota de correr. Mas e se cada porta que você comprou colocasse um molho de chaves embaixo do capacho?

Mas veja, eu desenvolvo em C++ (e C#, PowerShell, Ruby, Python, GoLang, praticamente qualquer coisa que vier no meu caminho.) Eu tenho o ConEmu e o TakeCommand instalados, junto com o mingw. Eu sei como segurar a tesoura enquanto corro.

O PowerShell _é_ uma falha de segurança. Uma ferramenta de automação muito útil, permitindo todo tipo de acesso inesperado. E o que estamos pedindo (modos mistos) é certamente mais seguro do que a alternativa (todos elevados). Realmente este (terminal) é uma ferramenta poderosa para usuários avançados, a maioria dos quais provavelmente entende muito bem o cenário de segurança... e entende compromisso pragmático.

A confiança zero só funciona quando não é debilitante.

@robomac Se pudéssemos convencer a equipe de segurança (que nos disse em várias ocasiões para não nos aventurarmos remotamente perto de elevação mista) que apenas pessoas que sabem segurar suas tesouras da maneira certa e não correr com elas _usariam_ este projeto, provavelmente faríamos isso. Não sei se eu mesma acredito. Aqui está o porquê:

Da mesma forma, se o Terminal estiver sendo executado em elevação mista (de um host Medium-IL para um cliente High-IL), ele ainda poderá ser forçado a receber entrada por qualquer outra coisa que esteja sendo executada como esse usuário. Mesmo que a pessoa por trás do teclado seja um santo e só eleve pelos dez segundos que ela precisa para elevar, _qualquer aplicativo executado em sua conta de usuário pode representar o administrador sem um prompt de elevação adicional_. Provavelmente totalmente despercebido, até.

@DHowett-MSFT Obrigado por responder. Você supõe que estamos permitindo que processos maliciosos sejam executados de qualquer maneira. Restringimos as permissões dos mantras de "Práticas recomendadas" que fazemos com nossa pose de cachorro voltado para baixo todas as manhãs, mas se você realmente tem uma preocupação de que algumas horas, até mesmo, de acesso elevado ao terminal o colocam em risco _em seu próprio sistema, você está desenvolvendo em_ ...

1. Você não deveria estar executando o Terminal e
2. Você deve limpar e começar de novo.

Eu garanto que um pesquisador de vírus (de computador) não deveria arriscar isso em um caminho vetorial... Mas "Terminal" não é para seus parentes desavisados; é uma ferramenta elétrica.

Existe uma maneira padrão de lidar com o risco. Trazido a você pelo mundo do navegador. Quando você vai para as bandeiras avançadas, você recebe um aviso de, grosso modo, "Aqui estão os dragões". (Acho que é precisamente isso em Pale Moon... que é o navegador de segurança hard-core sério.) Adicione o aviso (não-UAC, adicional), mas deixe o usuário decidir.

Uma outra pergunta: Duas sessões distintas do Terminal, uma elevada e outra não, se comportariam conforme o esperado? Ou ambos seriam vetores para qualquer sessão?

Eu não discordo que as pessoas devam ser capazes de optar por algo assim. :sorrir:

duas sessões distintas

Ah, sim, isso deve funcionar absolutamente hoje - e não ser um vetor (o elevado está totalmente em execução no lado High-IL do mundo e não pode ser conduzido por nenhum outro processo Medium-IL)

que deve funcionar absolutamente hoje

No mesmo espírito, 2 abas não podem rodar em processos diferentes e assim habilitar elevação mista na mesma janela?

@DHowett-MSFT Então, por que as duas sessões distintas não podem ser hospedadas no aplicativo abrangente? Realmente não é difícil de fazer.

Acho que entendo as implicações de segurança de ter aplicativos de console elevados em primeiro lugar, mas o que não consigo entender é por que ter dois tipos de guias (elevadas e não elevadas) no Windows Terminal seria _mais arriscado_ do que o Windows tem suporte por idades, ou seja, executando CMDs / PowerShell elevados e não elevados lado a lado. Alguém pode lançar alguma luz sobre isto?

@robomac
[1] É trivial quando você está _hospedando janelas tradicionais_ com alças de janela tradicionais. Isso funciona muito bem no caso do conemu, ou no caso do shell com abas, onde você pode assumir uma janela em uma sessão elevada e re-pai sob uma janela em uma sessão não elevada.

Quando você fizer isso, há alguns recursos de segurança que abordarei em [2]. Por causa disso, você pode criá-lo, mas não pode forçá-lo a fazer nada.

Há um problema, no entanto. O Terminal não é arquitetado como uma coleção de janelas que podem ser repaginadas. Por exemplo, ele não está executando um host de console e movendo sua janela para uma guia. Ele foi projetado para suportar uma "conexão" - algo que pode ler e escrever texto. É um primitivo de nível mais baixo do que uma janela. Percebemos o erro de nossos caminhos e decidimos que o modelo UNIX estava certo o tempo todo, e pipes, texto e fluxos estão _onde estão._

Dado que estamos usando ilhas Xaml para hospedar uma interface do usuário moderna e costurar uma superfície DirectX nela, estamos muito além do mundo dos identificadores de janela padrão. As ilhas Xaml são totalmente compostas em um único HWND, assim como Chrome e Firefox e a gama de jogos DirectX/OpenGL/SDL. Não temos componentes que possam ser executados em um processo (elevado) e hospedados em outro (não elevado) que não sejam as "conexões" mencionadas.

Agora, a pergunta óbvia de acompanhamento é _"por que você não pode ter uma conexão elevada em uma guia ao lado de uma conexão não elevada?"_ É aqui que @sba923 deve pegar a leitura (:smile:). Provavelmente vou abordar algumas coisas que você (@robomac) já conhece.

[2] Quando você tem duas janelas na mesma área de trabalho na mesma estação de janela, elas podem se comunicar entre si. Eu posso usar SendKeys facilmente através WScript.Shell para enviar entrada de teclado para qualquer janela que o shell possa ver.

A execução de um processo elevou _severs_ essa conexão. O shell não pode ver a janela elevada. Nenhum outro programa no mesmo nível de integridade que o shell pode ver a janela elevada. Mesmo que tenha uma alça de janela, não pode interagir com ela. É também por isso que você não pode arrastar/soltar do explorer para o bloco de notas se o bloco de notas estiver sendo executado elevado. Apenas outro processo elevado pode interagir com outra janela elevada.

Esse recurso de "segurança" (chame-o como quiser, provavelmente foi destinado a ser um recurso de segurança em um ponto) existe apenas para alguns tipos de objetos globais de sessão. As janelas são uma delas. Pipes não são realmente um deles.

Por causa disso, é trivial quebrar essa segurança. Tome o terminal como um exemplo disso. Se iniciarmos uma conexão elevada e a hospedarmos em uma janela _não elevada_, de repente criamos um conduíte através desse limite de segurança. A coisa elevada do outro lado não é uma janela, é apenas um aplicativo em modo texto. Ele imediatamente faz o lance do host não elevado.

Qualquer pessoa que possa _controlar_ o host não elevado (como WScript.Shell::SendKeys ) _também_ obtém um conduíte instantâneo através do limite de elevação. De repente, qualquer aplicativo de integridade média em seu sistema pode controlar um processo de alta integridade. Este pode ser o seu navegador, ou o minerador de bitcoin que foi instalado com o pacote left-pad do NPM, ou qualquer outra coisa.

É um risco pequeno, mas _é_ um risco.

Outras plataformas aceitaram esse risco de preferência para conveniência do usuário. Eles não estão errados em fazê-lo, mas acho que a Microsoft recebe menos "aprovação" em coisas como "aceitar o risco para conveniência do usuário". O Windows 9x foi um desastre de segurança absoluto, e contas de usuário limitadas e prompts de elevação e segurança em nível de kernel para gerenciamento de janelas foram a resposta para essas coisas. Eles não são fechaduras para serem afrouxadas levemente.

@DHowett-MSFT Muito obrigado pelo esclarecimento. Acho que teremos que nos acostumar a executar uma instância elevada do Windows Terminal e uma instância não elevada lado a lado, assim como estamos fazendo com aplicativos de console atualmente.

Fascinante. Obrigada. Terminal sendo mais um renderizador de conexão do que uma janela faz sentido. Isso dá ao PowerShell, já bastante focado em pipe/conexão, algum controle adicional sobre anteriormente em um console em janela?

As sessões de Terminal separadas são totalmente isoladas umas das outras?

Eu ficaria inteiramente satisfeito em apenas ter uma indicação de que estou em uma sessão elevada. Como "Administrador: \ Estou sentindo muita falta disso agora.

???

"Executar como usuário diferente" é uma coisa que todos os administradores do Windows precisam! Isso seria muito útil se estivesse disponível. A melhor opção seria tê-lo com um sinalizador na configuração para cada perfil.

BTW, falando de isolamento de janela, deixe-me citar o último relatório de vulnerabilidade do ctfmon

O ataque óbvio é um usuário sem privilégios injetando comandos em uma sessão do console do Administrador ou lendo senhas enquanto os usuários efetuam login. Até mesmo os processos do AppContainer em área restrita podem executar o mesmo ataque.

@ecki Essa é uma notícia bastante perturbadora. Tenho certeza de que Tavis vai festejar esta noite depois disso.

@DHDHowett-MSFT
Como muitos aqui escreveram, se o novo terminal não puder iniciar com a opção "executar como usuário diferente" do que para um grande número de usuários, não é muito utilizável, também não é compatível com o "modelo de camada administrativa do Active Directory" da Microsoft se, por exemplo, você tiver um usuário AD com direitos padrão e executar PS Scripts com um Adminuser em um controlador de domínio.

Eu não tenho muitos casos em que eu inicio um terminal com meu usuário conectado no momento… então eu pergunto a você, qual é o caso de uso deste Terminal? Ping, nslookup etc, se essa é a intenção, por que você está colocando tanto trabalho nisso tudo?

Com “executar como administrador” você tem alguns pontos válidos, mas por que outros consoles como (PS6/7) ainda suportam essas funções, se é tão inseguro?

Sempre pensei que o novo Terminal App substituiria todas as janelas cmd/PS/… separadas, mas parece que não é utilizável em muitos cenários do mundo real. Isso é meio triste tbm...

@Fisico sua experiência não é universal, e eu encorajo você a considerar isso ao pedir a alguém que justifique a própria existência de seu projeto.

Para o seu ponto geral sobre "executar como usuário diferente" não existente/não funcionando: essa é uma limitação da plataforma que estamos tentando eliminar. Não é por maldade ou incompetência que não a apoiamos.

Quanto ao motivo pelo qual outros aplicativos de console o suportam, não é inseguro quando o fazem, porque especificamente não hospedam diferentes níveis de elevação na mesma janela. Essa é a questão central aqui. Como eles são hospedados em processos autônomos com janelas autônomas, eles estão livres da restrição de manipulação entre níveis de integridade.

@DHowett-MSFT
Desculpe se te ofendi com meu post, não era minha intenção, coloquei muita emoção nele.
Eu acho que o Terminal é uma ótima ideia e tem um potencial muito grande e estou feliz que você está desenvolvendo com a comunidade para tirar o máximo proveito dele.

Neste ponto, há tanta confusão sobre o que é implementado e o que não.
"Executar como administrador" para todo o aplicativo está funcionando no momento, isso veio para ficar?

Pelo que entendi, “Executar como administrador” para cada guia/perfil não é algo que você deseja implementar. Eu acho que isso é bom para a maioria de nós.

“Executar como usuário diferente” não é possível porque o Windows não oferece suporte para aplicativos e você/nós temos que esperar até que o Windows o suporte? Se sim, estamos falando de anos?

“Executar como usuário diferente” por guia/perfil também é algo que você não deseja implementar?

@DHDHowett-MSFT
Como muitos aqui escreveram, se o novo terminal não puder iniciar com a opção "executar como usuário diferente"
do que para um grande número de usuários não é muito útil, ... Eu sempre pensei que o novo Terminal App
substitua todas as janelas cmd/PS/… separadas, mas parece que não é utilizável em muitos cenários do mundo real. Isso é meio triste tbm...

Eu não concordo. Este é um grande avanço em relação ao que tínhamos antes. Infelizmente, a maioria de nós provavelmente adquiriu o hábito de executar nossos shells elevados devido à falta de uma abordagem mais granular... e ainda podemos. Não podemos _misturar_ eles... mas nunca fizemos. Sério, nas _últimas três_ empresas em que estive, o Developer Wiki fez todas as compilações/testes em um prompt VS elevado. Implementamos a segurança por meio de varreduras em tempo real, firewalls ativos agressivos e sabendo que nossos desenvolvedores raramente fazem besteira. Os _não-desenvolvedores_ nunca executam elevados, porque (1) não podemos confiar neles e (2) eles não precisam.

Então, eu, por exemplo, aprecio este novo Terminal. Não é perfeito, mas também não é o Take Command/TCC. Pelo menos isso é padrão.

@DHDHowett-MSFT
Como muitos aqui escreveram, se o novo terminal não puder iniciar com a opção "executar como usuário diferente"
do que para um grande número de usuários não é muito útil, ... Eu sempre pensei que o novo Terminal App
substitua todas as janelas cmd/PS/… separadas, mas parece que não é utilizável em muitos cenários do mundo real. Isso é meio triste tbm...

Eu não concordo. Este é um grande avanço em relação ao que tínhamos antes. Infelizmente, a maioria de nós provavelmente adquiriu o hábito de executar nossos shells elevados devido à falta de uma abordagem mais granular... e ainda podemos. Não podemos _misturar_ eles... mas nunca fizemos. Sério, nas _últimas três_ empresas em que estive, o Developer Wiki fez todas as compilações/testes em um prompt VS elevado. Implementamos a segurança por meio de varreduras em tempo real, firewalls ativos agressivos e sabendo que nossos desenvolvedores raramente fazem besteira. Os _não-desenvolvedores_ nunca executam elevados, porque (1) não podemos confiar neles e (2) eles não precisam.

Então, eu, por exemplo, aprecio este novo Terminal. Não é perfeito, mas também não é o Take Command/TCC. Pelo menos isso é padrão.

elevado != executado como usuário diferente.
Eu executo o PowerShell mais com outros usuários do AD e depois com o meu.
Estou com você que muitas vezes você executa um cmd ou PS como administrador, mesmo que não precise, mas há muitos casos em que você precisa executá-lo como administrador. A maioria das tarefas sysadmin requer direitos de administrador ou um usuário diferente com algum tipo de privilégio.
Claro, se você precisar executar cmd's no contexto do usuário, está tudo bem.

Eu entendo que "elevado! = execute como usuário diferente". Eu simplesmente não acredito que "executar como usuário diferente" seja tão comum quanto você afirma.

Eu entendo que "elevado! = execute como usuário diferente". Eu simplesmente não acredito que "executar como usuário diferente" seja tão comum quanto você afirma.

Se você tem algo a ver com o universo da Microsoft, é absolutamente necessário.
Não é a melhor ideia fazer login em máquinas Windows com direitos de administrador de domínio, por exemplo.
Executar scripts PS com um usuário que tenha direitos de administrador de domínio ou alguns outros direitos é muito comum.

@Fisico por que não usar o comando New-PSSession então?

Scripts automatizados que exigem algum tipo de elevação específica para um serviço geralmente exigem 'executar como usuário diferente'. Se isso se aplica ao Terminal é uma história diferente. Você sempre pode alterar seu login uma vez em uma sessão CMD ou PS usando o comando runas . Isso não alteraria o estado de elevação da guia, pois está utilizando o logon subjacente, que é seu usuário regular. Além disso, qualquer script que você executar usando o Agendador de Tarefas ou um trabalho cron não exigirá que o Terminal seja executado, a menos que você o esteja utilizando para obter uma funcionalidade que de alguma forma não existe em uma sessão normal do console. Se for esse o caso, a utilização de parâmetros para executar esse script com o Terminal, que inicia como um processo em segundo plano, seria a solução.

Portanto, a elevação mista para guias não é necessária. Temos uma solução alternativa e é fácil copiar os comandos runas específicos que você precisa para um arquivo txt que você pode copiar/colar no Terminal e depois preencher sua senha (você nunca deve salvar sua senha em nada que não seja criptografado).

@SamuelEnglard
eu não quero me conectar a um host remoto, para executar um script.

@WSLUser sim, é uma opção usar runas, mas é muito mais conveniente simplesmente executar o terminal ou PS como um usuário diferente. Não vejo por que isso deveria ser um problema.

@Fisico New-PSSession não precisa se conectar a um computador remoto, veja a segunda primeira entrada de sintaxe.

@SamuelEnglard
eu não quero me conectar a um host remoto, para executar um script.

@WSLUser sim, é uma opção usar runas, mas é muito mais conveniente simplesmente executar o terminal ou PS como um usuário diferente. Não vejo por que isso deveria ser um problema.

É uma operação bastante padrão para um usuário fixar o PowerShell na barra de tarefas e clicar com o botão direito do mouse para executar como Admin ou em alguns ambientes RunAs OtherUser, pois uma conta elevada é necessária para executar um script de nível empresarial. Dizer que não é possível para o terminal é como os ambientes que aproveitam o PSLockDown e forçam o RunAs Admin apenas para carregar o shell ou o VSCode
Na minha humilde opinião

Se você realmente precisar executar uma guia como um usuário diferente, poderá ter um perfil que execute New-PSSession -Credential | Enter-PSSession no início.

ISENÇÃO DE RESPONSABILIDADE: Não me responsabilizo por computadores arruinados por fazer isso.

Se você realmente precisar executar uma guia como um usuário diferente, poderá ter um perfil que execute New-PSSession -Credential | Enter-PSSession no início.

> AVISO LEGAL : Não me responsabilizo por computadores arruinados por isso.

Claro, ou a "segurança" aqui poderia ser reconsiderada. Novamente, eu coloco o PowerShell na minha barra de tarefas, a partir daí posso iniciar o PowerShell não elevado; Posso clicar com o botão direito do mouse e escolher "Executar como administrador" e, se em um ambiente corporativo, posso clicar com o botão direito do mouse no ícone, clicar com o botão direito do mouse em "Windows PowerShell" e selecionar "Executar como usuário diferente" para iniciar o PowerShell com credenciais alternativas. Sem sessões, sem RDP para outro host para obter esses creds.

Claro, ou a "segurança" aqui poderia ser reconsiderada. Novamente, eu coloco o PowerShell na minha barra de tarefas, a partir daí posso iniciar o PowerShell não elevado; Posso clicar com o botão direito do mouse e escolher "Executar como administrador" e, se em um ambiente corporativo, posso clicar com o botão direito do mouse no ícone, clicar com o botão direito do mouse em "Windows PowerShell" e selecionar "Executar como usuário diferente" para iniciar o PowerShell com credenciais alternativas. Sem sessões, sem RDP para outro host para obter esses creds.

Sim, e também posso fazer isso com o Windows Terminal. Acordado. Não vejo como isso ajuda aqueles que desejam ter uma mistura de guias que estão sendo executadas como usuários diferentes (ou elevação diferente).

"guias mistas" à parte, só quero esclarecer, você NÃO PODE fazer isso com (a visualização lançada) Windows Terminal devido ao design dos aplicativos da Windows Store. Você só pode executar como o usuário que instalou esse aplicativo e fez login como esse mesmo usuário.

Tudo o que quero é poder fazer o que faço hoje, entrar no PC como usuário normal e executar shells elevados. Se o Windows Terminal for lançado como está, é pouco útil para mim.

Ponto muito bom. Essa limitação não existe com compilações privadas (sem armazenamento) do Windows Terminal.

"guias mistas" à parte, só quero esclarecer, você NÃO PODE fazer isso com (a visualização lançada) Windows Terminal devido ao design dos aplicativos da Windows Store. Você só pode executar como o usuário que instalou esse aplicativo e fez login como esse mesmo usuário.

Tudo o que quero é poder fazer o que faço hoje, entrar no PC como usuário normal e executar shells elevados. Se o Windows Terminal for lançado como está, é pouco útil para mim.

Acabei de abrir 2 instâncias da compilação da loja do Windows Terminal - uma elevada e outra não. Então eu não sei por que não está funcionando para você.

Ok, eu tenho que acreditar que você é um administrador local no seu PC. Para ser claro, talvez eu deva esclarecer. Eu nunca sou um administrador local na minha estação de trabalho. Então, quando vou para 'executar como administrador', sou solicitado a fornecer usuário/senha.

A conta 'admin' que uso é diferente da minha conta normal de leitura de malware/e-mail. Então, tecnicamente, o que eu faço é executar como usuário diferente. Esta é a limitação do aplicativo da Windows Store. A solução (e talvez eles façam isso) é lançar isso como um componente do Windows que não terá essas limitações.

* [URGENTE] TUDO QUE ENCONTREI UMA SOLUÇÃO PARA ESTE PROBLEMA! * *

Seguindo este guia
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
você pode tornar a pasta do aplicativo do Windows sua!

depois de fazer isso, você pode localizar a pasta Microsoft.WindowsTerminal._blahblahYourVersion_ . Uma vez dentro, localize WindowsTerminal.exe Mostrado abaixo

Depois de encontrá-lo, crie um atalho para este arquivo e coloque-o onde quiser. Depois de fazer isso, configure-o para ser executado como administrador. Você pode fazer isso clicando com o botão direito e indo em _Propriedades>Avançado>Executar como administrador_ Depois disso, clique em OK e está tudo pronto!

Pessoalmente, eu precisava disso porque uso o atalho na minha barra de tarefas para que eu possa clicar em _Windows + 1_ para iniciá-lo como administrador. Não é o longo caminho para navegar pelo meu menu iniciar para executá-lo corretamente.

Você também pode descompactar o pacote que colocamos na página de lançamentos. É apenas um arquivo ZIP. Observe que _não suportamos oficialmente_ execução não empacotada!

Mas isso ainda significa que não há uma maneira _suportada_ de executar elevado! Acho que esse é um recurso obrigatório.

Na verdade, estou corrigido.

O que está faltando é a entrada "executar como administrador" no menu de atalho da barra de tarefas.

Falei com algumas pessoas ontem em um encontro e algumas pessoas disseram que lançam principalmente o powershell com Windows + X e adorariam ter terminal / terminal como administrador lá.

Ponto muito bom!

Esse é exatamente o meu ponto! Esta é a solução para executá-lo na barra de tarefas
com privilégios de administrador!

No domingo, 25 de agosto de 2019, 1h08 Stéphane BARIZIEN [email protected]
escrevi:

Ponto muito bom!

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q#issuecomment-5246033WW2ZLOORPWSZGOD5CNA6Q#issuecomment-5246033LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

Na verdade, estou corrigido.

O que está faltando é a entrada "executar como administrador" no menu de atalho da barra de tarefas.

Na barra de tarefas, clique duas vezes com o botão direito. Uma vez no ícone para fazer aparecer o menu de contexto, depois uma segunda vez no nome do aplicativo. por exemplo, "Windows Terminal (Preview)" e escolha "Executar como administrador"

Eu me sinto confuso.

Rubor.

Envergonhado.

Como é que eu não pensei nisso?

Obrigado de qualquer forma por compartilhar com todos nós!

Vejamos o problema do outro lado...
O Windows permite que processos não elevados controlem outros processos não elevados, enviando pressionamentos de tecla, capturando sua interface do usuário etc., mas impede que processos não elevados façam isso em uma janela de um processo elevado.
O Windows Terminal foi projetado para ser usado também para gerenciar servidores remotos, através de ssh, PowerShell remoting, etc...
Isso significa que o Windows Terminal se torna uma falha de segurança assim que é usado para administração, pois um malware local pode esperar por uma sessão do Windows Terminal para espionar o que o usuário está fazendo e, assim que detectar um shell remoto, tente injetar comandos para infectar o servidor usando direitos de administrador.

Impedir que o Windows Terminal seja executado como administrador não parece uma melhoria de segurança, pois executá-lo como administrador protegeria o usuário de processos não elevados que sequestram suas sessões remotas de shell. Executá-lo como administrador deve ser recomendado ao usuário sempre que usar uma ferramenta que forneça um prompt de comando elevado, local ou remotamente.

E sobre o sudo para Windows, a execução do serviço sshd e a conexão com o localhost a partir de um shell não elevado exibem o mesmo problema de segurança?

Isso significa que o Windows Terminal se torna uma falha de segurança assim que é usado para administração, pois um malware local pode esperar por uma sessão do Windows Terminal para espionar o que o usuário está fazendo e, assim que detectar um shell remoto, tente injetar comandos para infectar o servidor usando direitos de administrador.

Embora seja verdade que o sistema remoto possa ser infectado (supondo que o processo remoto tenha direitos de administrador), isso não significa que também devemos deixá-lo infectar o sistema local.

Impedir que o Windows Terminal seja executado como administrador não parece uma melhoria de segurança, pois executá-lo como administrador protegeria o usuário de processos não elevados que sequestram suas sessões remotas de shell. Executá-lo como administrador deve ser recomendado ao usuário sempre que usar uma ferramenta que forneça um prompt de comando elevado, local ou remotamente.

Nada está impedindo você de executar o Windows Terminal com direitos de administrador agora. O problema em questão é ter abas elevadas e não elevadas misturadas.

@SamuelEnglard local na resposta.

Para adicionar, o que estamos tentando fazer é evitar adicionar _novas_ brechas de segurança. O console original apresentava os mesmos problemas de gerenciamento de servidor remoto. Nada podemos fazer sobre isso, infelizmente. Os usuários que fazem o gerenciamento remoto do servidor estão sempre executando seus consoles/terminais elevados, e isso lhes dará alguma segurança adicional (embora eu não seja especialista em segurança e não interpretaria essa declaração como um conselho)

Ideia para progredir neste problema: Tente executar o _app_ inteiro como elevado e, se isso for bem-sucedido, adicione um botão ao lado de cada botão "abrir" com o ícone de um escudo UAC e adicione um atalho de teclado para abrir uma guia elevada: Ctrl Shift E . (Eu verifiquei e isso não estava vinculado.) Funciona apenas para a próxima guia aberta.

De qualquer forma, as guias abertas têm um ícone do UAC antes do ícone normal e são executadas como administrador. (Lembre-se, os programas não podem mais enviar essas chaves. Executamos o aplicativo como administrador.)

O aplicativo deve tentar elevar automaticamente e, se isso falhar, execute normalmente e ignore todo esse thread.

Na verdade, estou corrigido.
O que está faltando é a entrada "executar como administrador" no menu de atalho da barra de tarefas.

Na barra de tarefas, clique duas vezes com o botão direito. Uma vez no ícone para fazer aparecer o menu de contexto, depois uma segunda vez no nome do aplicativo. por exemplo, "Windows Terminal (Preview)" e escolha "Executar como administrador"

Apenas notei que o prompt do UAC nesse caso diz "Programa desconhecido".

Bastante inesperado se você me perguntar...

@sba923 isso é #2289 :smile:

@DHowett-MSFT obrigado pela informação; bom saber que (já) é rastreado.

A melhor resposta para isso que posso pensar é ter a opção de ter um perfil que deve ser elevado e, se as janelas atuais não forem elevadas, inicie uma nova instância elevada com esse perfil. (Pense como as sessões de navegação privada funcionam)

Muito boa ideia

Eu usei desta forma para adicionar o Terminal no menu Win+X:
Crie um novo atalho com o destino:
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!App
editar:
Desculpe, isso não funcionará se você quiser executar o aplicativo como administrador.
Em vez disso, você pode usar nircmd e criar um atalho com
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(o caminho correto para "Microsoft.WindowsTerminal_xxxxxxxxxxxx" pode ser encontrado com o comando PS "Get-appxpackage *WindowsTerminal*", use a entrada em PackageFamilyName)

Este atalho pode ser usado para iniciar o terminal com privilégios de administrador com um simples clique duplo e com WinXEditor pode ser adicionado no menu Win+X.
Nota: O terminal também deve ser instalado na conta de administrador.

A ideia é carregar todos os perfis como Administrador ou apenas alguns? Idealmente, eu gostaria de tê-lo por perfil individual. Talvez um imóvel que seja a conta "runas" e outro como "iselevado"?

Conforme discutido detalhadamente neste tópico, você não pode ter uma mistura de elevado e não elevado na mesma instância do Windows Terminal, e isso não será adicionado.

Na verdade, estou corrigido.
O que está faltando é a entrada "executar como administrador" no menu de atalho da barra de tarefas.

Na barra de tarefas, clique duas vezes com o botão direito. Uma vez no ícone para fazer aparecer o menu de contexto, depois uma segunda vez no nome do aplicativo. por exemplo, "Windows Terminal (Preview)" e escolha "Executar como administrador"

FWIW, acabei de testar shift e clique com o botão direito do mouse, o que fornece a opção "Executar como administrador" imediatamente - apenas um pouco mais rápido do que a opção de dois cliques com o botão direito que anteriormente era minha opção.

Ei pessoal você esqueceu o UAC? O aplicativo não pode clicar em coisas na área de trabalho segura.

FWIW, acabei de testar shift e clique com o botão direito do mouse, o que fornece a opção "Executar como administrador" imediatamente - apenas um pouco mais rápido do que a opção de dois cliques com o botão direito que anteriormente era minha opção.

Você também pode ctrl + shift + clique com o botão esquerdo no ícone para abrir o UAC instantaneamente.

Ótimo, muito obrigado! Quantos atalhos temos que lembrar? ;-)

Para o seu ponto geral sobre "executar como usuário diferente" não existente/não funcionando: essa é uma limitação da plataforma que estamos tentando eliminar. Não é por maldade ou incompetência que não a apoiamos.

Quanto ao motivo pelo qual outros aplicativos de console o suportam, não é inseguro quando o fazem, porque especificamente não hospedam diferentes níveis de elevação na mesma janela. Essa é a questão central aqui. Como eles são hospedados em processos autônomos com janelas autônomas, eles estão livres da restrição de manipulação entre níveis de integridade.

Definitivamente espero que correr como um usuário diferente seja algo que venha em algum momento. Embora não seja a maioria das minhas atividades diárias, alguns cmdlets do powershell exigem elevação (e eu corro com usuários diferentes, pense em um administrador de usuário protegido).

Não é o fim do mundo, mas certamente será irritante ter que voltar aos shells herdados.

Com o tempo, eu acho!

Não há absolutamente nenhum problema / limitação com o uso do Windows Terminal elevado, portanto, não há necessidade de ficar com os "shells herdados" (ou para ser mais exato: para o host do console herdado).

É só que você não pode misturar elevado e não elevado em (diferentes guias) na mesma instância .

Não há absolutamente nenhum problema / limitação com o uso do Windows Terminal elevado, portanto, não há necessidade de ficar com os "shells herdados" (ou para ser mais exato: para o host do console herdado).

É só que você não pode misturar elevado e não elevado em (diferentes guias) na mesma instância .

Acho que posso ter interpretado mal o que foi dito acima, mas há uma limitação de plataforma ao executar o terminal em um contexto de usuário diferente do que estou lendo.

Acho que posso ter interpretado mal o que foi dito acima, mas há uma limitação de plataforma ao executar o terminal em um contexto de usuário diferente do que estou lendo.

Yah, este tópico tem sido todo o tabuleiro sobre esse ponto. Eu não sou um administrador em minhas estações de trabalho, então 'executar como administrador' apenas me pede para inserir meus 'credenciados elevados'.

Provavelmente deveríamos simplesmente ter um novo tópico sobre esse caso de uso.

Para ser claro, o que quero dizer (e acho que muitos 'administradores' precisam) é a capacidade de estar logado em nossa estação de trabalho como um usuário normal. Em seguida, execute 'algum shell' como um usuário elevado, como no administrador de domínio, para fazer o trabalho do AD.

Certo ou errado, isso é o que alguns de nós fazemos e precisamos. Todos os truques sobre como instalar o Console da loja como esse usuário e criar atalhos inteligentes realmente não funcionaram para mim.

E sim, posso fazer isso de várias maneiras e talvez devesse restringir algumas dessas atividades a uma estação de trabalho protegida, mas a realidade é que, como usuário normal, geralmente não preciso de um shell.

IMVHO a confusão decorre do fato de que as pessoas são (mantenha hábitos pré-Vista morrendo de dificuldade) mais ou menos alternadamente usando os termos "elevado" e "como outro [domínio] [administrador] usuário".

A execução como outro usuário não é a mesma coisa que a execução elevada.

1. Algumas das pessoas neste segmento têm a necessidade, quando conectadas como usuário administrador, de executar cargas de trabalho do Windows Terminal com elevação.

2. Algumas outras pessoas têm a necessidade, quando conectadas como um usuário normal (ou não administrador de domínio), de executar cargas de trabalho do Windows Terminal como outro usuário administrador, normalmente com elevação.

3. Pode-se também considerar o caso em que as pessoas estão conectadas como usuário A normal e desejam executar cargas de trabalho do Windows Terminal como usuário B sem elevação.

Em #2 e #3, a implantação baseada na Windows Store torna a história mais complexa, porque o Windows Terminal não será executado como o usuário conectado, onde os "aplicativos de armazenamento" são implantados para esse usuário.

Espero ter entendido a situação corretamente. Se eu fizer isso, espero que isso esclareça um pouco o assunto.

Você acertou exatamente.

Apenas FYI, esse problema exato, incapaz de elevar ("Executar como administrador", em vez de executar como outro usuário administrativo, "Executar como usuário diferente") quando a conta com a qual você está conectado não é um administrador local no sistema, conforme as melhores práticas), foi brevemente abordado em outra edição: https://github.com/microsoft/terminal/issues/1538 . Isso foi fechado com uma explicação de ser um problema do Windows, não um problema do Terminal, pois parece ser uma limitação dos aplicativos da Loja.

Sem entrar em um debate sobre se isso deveria ter sido lançado como uma instalação MSI em vez de usar a Loja, há uma solução alternativa nesse segmento que usei; faça login brevemente como sua conta de administrador, instale o aplicativo da Loja e, em seguida, faça o logout novamente. Executar como administrador funcionou para minha conta de usuário normal (até a próxima atualização, quando terá que ser feito novamente).

Sim, deve haver um MSI disponível. Meu novo empregador não permite instalações (públicas) da Loja, então a única maneira de poder usar o Windows Terminal será compilar a partir da fonte ...

Decepcionado ao ver que você não pode executar o Windows Terminal "como administrador" sem erros e, em seguida, ter que implementar uma solução alternativa. Eu diria que muitas empresas implementam uma abordagem de separação de privilégios para identidades (com funcionários de TIC tendo uma conta privilegiada e não privilegiada). Portanto, ser capaz de acomodar esse requisito fornecendo uma implantação MSI opcional conforme a sugestão @sba923 seria uma abordagem interessante até que esses aplicativos agrupados de armazenamento de tempo possam lidar com a separação de privilégios?

Esta é uma PREVIEW nem mesmo a versão 1.0...

Sinto que este tópico foi bastante bem discutido neste momento, mas há uma perspectiva que ainda não entendi: por que não podemos criar um atalho do Windows para este aplicativo? Essa é a solução típica para "sempre iniciar como administrador" - a solução típica é criar um atalho e alterar o atalho para usar o acesso elevado como padrão.

Alguém pode me explicar por que não podemos criar um atalho para este aplicativo? Isso provavelmente está mais relacionado ao funcionamento interno do Windows do que ao funcionamento interno do Terminal, mas sinto que estamos fazendo rodeios se eu não perguntar diretamente.

Obrigado.

Eu mantenho nircmd na minha pasta c:\utils junto com muitas outras ferramentas comumente usadas.
Eu adicionei um perfil que se parece com isso:

        {
            "name": "Admin Terminal",
            "startingDirectory": "c:\\utils\\",
            "commandline": "cmd.exe /q /c nircmd elevate \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
            "hidden": false
        },

Ele traz uma solicitação de elevação do UAC e, em seguida, abre uma instância de administrador do Windows Terminal. É uma solução decente para o momento.

Eu ficaria bem com a capacidade de marcar sessões como Elevadas e abri-las em uma nova janela, honestamente.

Eu vim aqui procurando uma solução legal, mas como parece não existir, vou compartilhar minha solução hacky. Eu adicionei um perfil para executar o powershell elevado:

{
...
  "commandline" : "powershell.exe -Command \"Start-Process PowerShell -Verb RunAs\"",
...
}

Ele aparece em uma janela separada, mas faz o trabalho.

Sinto que este tópico foi bastante bem discutido neste momento, mas há uma perspectiva que ainda não entendi: por que não podemos criar um atalho do Windows para este aplicativo? Essa é a solução típica para "sempre iniciar como administrador" - a solução típica é criar um atalho e alterar o atalho para usar o acesso elevado como padrão.

Alguém pode me explicar por que não podemos criar um atalho para este aplicativo? Isso provavelmente está mais relacionado ao funcionamento interno do Windows do que ao funcionamento interno do Terminal, mas sinto que estamos fazendo rodeios se eu não perguntar diretamente.

Obrigado.

@aaronsteers , você está certo de que é mais sobre o Windows do que sobre o Terminal. O principal problema aqui é que somos distribuídos e instalados como um "pacote de aplicativo moderno". Eles têm várias restrições e limitações acidentais em comparação com aplicativos nativos, mas é necessário para o Terminal porque também é a maneira menos difícil de usar componentes da "API moderna do Windows" (WinRT). É terrivelmente frustrante para todos na equipe quase o tempo todo. :sorrir:

Estamos tentando transformar essa frustração e a frustração da comunidade em avanço para a plataforma. Peço desculpas, porém, essa mudança não é rápida aqui no Windows!

@DHowett Estou realmente tentando entender, porque gosto de 2/3 do Terminal, mas não está fazendo o básico com o qual estou acostumado com TakeCommand ou ConEmu, etc.

Não consigo misturar elevações nas várias abas. Se estou entendendo, é porque você é um tipo diferente de aplicativo e não está realmente hospedando o shell?

O buffer de rolagem nunca é limpo, em nenhum dos três ambientes (cmd, PowerShell, wsl bash). Isso acontece nos meus shells normais. Novamente, por causa de como está hospedado?

E seria muito bom ter um contexto ou menu suspenso mais acessível. Por exemplo, para limpar essa rolagem, considerando que mesmo o truque de escape do console não funcionou para mim.

A integração dos ambientes e o quão bem ele pega os shells do WSL Linux é muito bom. Mas está custando muita usabilidade por causa dos problemas de elevação e rolagem, então raramente o uso.

@robomac Há um ótimo post de @DHowett-MSFT aqui que explica por que não podemos misturar guias elevadas e não elevadas na mesma janela não elevada.

O tl; dr é: Se permitirmos que os usuários se conectem a linhas de comando elevadas a partir de uma janela do Terminal não elevada, isso cria uma falha de segurança gigante, onde outros aplicativos não elevados podem efetivamente conduzir o processo elevado, por meio da janela Terminal.

Não sei como o ConEmu mitiga esse risco, se é que o faz. É perfeitamente possível que seja uma falha de segurança que o conemu cria e que não nos sentimos confortáveis ​​em enviar como parte do Windows Terminal.

O resto de suas preocupações são todos os problemas que são rastreados em outras partes deste repositório, sugiro pesquisá-los para acompanhar seu progresso individualmente. Preferimos manter este tópico no único tópico de "elevação mista de guias"/"ter um perfil que inicia elevado"

No tópico: eu quero experimentar a rota "iniciar outra instância elevada" para perfis "elevados". Se a experiência do usuário não for tão ruim, então esse é um caminho possível aqui, pelo menos como uma opção.

A ConEmu não mitiga esse risco. Eles passam esse risco para seus usuários. (Eu nem tenho certeza de que eles estão documentando esse risco.)

No tópico "iniciar outra instância elevada": Eu não me importaria com esse comportamento, desde que ele pudesse usar a mesma instância elevada do Terminal para essas guias e não iniciar uma nova instância toda vez que eu invocar um perfil "elevado".

Na minha opinião, o "gigante" dessa brecha de segurança é um pouco exagerado. Não é normal ter um malware no computador que fica esperando por uma chance de ser elevado, então sacrificar a conveniência pela segurança não parece certo.

Por outro lado, se o objetivo final for que o WT seja enviado com o Windows como um terminal padrão, isso aumentaria drasticamente a superfície de ataque. Mas, novamente, neste caso, eu pessoalmente mitigaria um risco usando uma alternativa impopular que provavelmente não seria um alvo para tal ataque e fornecesse a conveniência necessária (supondo que detectar a presença de uma guia elevada em um terminal não seja trivial o suficiente para ser específico do terminal).

Parte disso é tl; dr para mim, mas se você pegar e despejar o pacote, poderá executar wt fora do sandboxing, o que significa elevação, e executar conforme o usuário diferente funciona sem problemas. Eu conversei com a MSFT no ignite sobre isso e me disseram para enviar uma solicitação de pull, mas minhas habilidades de VS são bastante fracas. O que seria bastante fácil de fazer é assiná-lo corretamente (teve que fazer isso com meu próprio pki interno para que eu pudesse executar no applocker) e colocá-lo em um formato distribuível MSI ou MSIX. Há um bug estranho aqui ou ali que pode ser específico para executá-lo dessa maneira, mas no geral funciona muito bem. Por enquanto eu só tenho uma função para extrair, assinar e substituir/atualizar uma versão baseada em arquivos de programa da versão baseada em armazenamento.

Eu entendo o risco desse recurso de "conectar" abas elevadas em um processo não elevado, mas não é possível fazer o contrário?
Meening para as pessoas como precisa disso, deixar o próprio Terminal também rodar como Elevado e permitir iniciar abas não elevadas?
Claro, isso tem outras desvantagens, mas para mim (e acho que para os outros também) são aceitáveis.
(claro, isso pode ser "interessante", pois o terminal é um aplicativo da loja do Windows, não tenho certeza se isso funciona)

Ps. Desculpe por reabrir este problema (também se outra pessoa já fez essa sugestão e eu "li" isso).

Graças ao @EmTschi , fiz uma solução simples e 100% conveniente
Ele usa o menu de contexto e age da mesma forma que o PowerShell 7
https://github.com/nt4f04uNd/wt-contextmenu
Lá você pode encontrar um guia de como implementá-lo e todos os arquivos necessários

Obrigado pela dica, vou tentar isso mais tarde.
Atualmente estou trabalhando com dois atalhos na minha área de trabalho, que são mapeados para as teclas Ctrl + Alt + T e Ctrl + Alt + Shift + T para um terminal elevado, também é uma solução alternativa, mas ... como poderia ser e a quilômetros de distância de algo como sudo.

@

Sempre que tento executar o aplicativo Terminal com uma conta de administrador, clique com o botão direito -> executar como administrador, o UAC aparece duas vezes e ocorre um erro dizendo:
"O Windows não pode encontrar (path\WindowsTerminal.exe) Certifique-se de ter digitado ...".
O caminho existe e o aplicativo funciona corretamente para o usuário não administrador que criou o aplicativo, mas o outro usuário administrador não consegue executá-lo.
Se eu fizer login no usuário admin, o aplicativo do terminal não estará presente nas configurações ou no menu iniciar, como se nunca tivesse sido instalado no sistema.
Existe uma maneira de criar o aplicativo para que ele seja instalado para todos os usuários? Ou a raiz do projeto precisa estar em um diretório não específico do usuário?

Estou vendo o mesmo problema acontecendo também.

Versão do Windows 18922.1000

Acabei de instalar na atualização 1909 do Win10 e tenho o mesmo problema ao tentar executar como administrador

Mesmo problema aqui. Não posso usar o terminal do Windows agora porque sempre preciso executar o docker e sempre preciso ser administrador no terminal ...

Eu tenho uma solução hack-around para quem quiser:

1. baixe o msixbundle da página de lançamento
2. descompacte que, lá dentro, encontre o msix que é para sua plataforma (normalmente o x64)
3. descompacte isso em uma pasta em algum lugar
4. copie essa pasta onde quiser e execute o WindowsTerminal.exe elevado ou como quiser

Muito dessa falha parece vir da conveniência de ter isso como um aplicativo de loja. Há uma discussão sobre isso em # 1386 e alguém mencionou talvez instalar com o Scoop, que automatiza o processo de extração acima.

Seria bom se os seguintes fossem tratados como cidadãos de primeira classe:

1. Instalações portáteis (arquivos zip - mesmo que a configuração ainda não seja portátil, pois fica em AppData\Local ao ficar sem área de instalação da loja do Windows)
2. Um instalador .exe antigo e regular (ou, se necessário, .msi) para pessoas que não querem a Loja ou usam o Instalador da Loja

Ambos não são tão complicados de implementar a partir do procedimento de compilação atual, como evidenciado pela automação do Scoop. E agora que o Windows Terminal está ficando muito bom, gostaria de poder usá-lo como qualquer outro terminal.

Já que estamos no assunto: a menos que haja incompatibilidades de API, seria ótimo ter a opção de instalar o Windows Terminal sem a Loja (mesmo a maneira "portátil") em versões anteriores do Windows 10 (meu empregador nos bloqueia em 1809/ RS5 e a instalação da Loja está bloqueada).

@sba923 se não confiássemos em APIs que existem apenas em 1903, não precisaríamos de 1903.

Claro... foi o meu palpite 😜

Terá que fazer lobby para atualizar toda a empresa, provavelmente atingirá um muro ...

Isso é tão estupido.

Vamos criar um novo terminal unificado para prompt de comando, powershell e bash para windows.
Posso executar cmd.exe como administrador?
Não.

Acho que vou manter meus ícones cmd.exe e powershell predefinidos para serem executados como administrador na minha barra de tarefas indefinidamente.

Coisas idiotas como essa é o motivo pelo qual minha máquina de trabalho principal ainda é um Macbook.

Isso é tão estupido.

Vamos criar um novo terminal unificado para prompt de comando, powershell e bash para windows.
Posso executar cmd.exe como administrador?
Não.

Acho que vou manter meus ícones cmd.exe e powershell predefinidos para serem executados como administrador na minha barra de tarefas indefinidamente.

Coisas idiotas como essa é o motivo pelo qual minha máquina de trabalho principal ainda é um Macbook.

Concordo neste caso. Eu quero uma única janela do Windows Terminal que abrigue todas as guias de terminal de que preciso, onde cada guia de terminal pode ser um dos vários hosts de terminal instalados e ser elevada ou não.

Realmente parece que esse recurso de elevação mista está sendo retido pela decisão de design técnico de hospedar todas as guias em uma única alça HWND.

1) Você pode executar o novo terminal como Admin? SIM (Há problemas ao fazê-lo, dependendo de como você o instalou/iniciou, mas não há desejo de que isso não funcione). (Se você não sabe como fazer isso, veja vários posts acima sobre como.

2) Você pode ter uma aba com elevação enquanto outra não é? Não . Consulte https://github.com/microsoft/terminal/issues/632#issuecomment -519375707 para saber o motivo.

As pessoas podem lembrar que este problema é sobre guias de elevação mistas?!? Se você deseja iniciar todo o processo elevado e não pode, por favor, abra um novo problema.

@DHowett-MSFT Podemos renomear esse problema para as guias de elevação mistas?

Independentemente da maneira como isso é tratado ou não, terminais ou guias elevados devem ter algum tipo de indicador. Agora, se eu iniciar um novo terminal com Executar como administrador, não há como perceber facilmente que minhas guias cmd têm acesso elevado em comparação com as da próxima janela.

EDITAR após o comentário de @SamuelEnglard : Obviamente eu escolhi apressadamente cmd como um mau exemplo. Sim, cmd mostra 'Administrador:' no título da guia. Mas o WSL Ubuntu bash na minha guia padrão substitui o que quer que possa haver no título da guia. Eu acho que bash não sabe (ou mesmo se importa) sobre a elevação do Windows Terminal, então essa informação não pode ser usada ao atualizar o título de dentro de bash (é claro que sudo situação, mas isso é uma coisa diferente).

No profiles.json do Terminal, há
"showTabsInTitlebar": false
mas com esta configuração a barra de título do Terminal não sinaliza a elevação.

@janilahti não faz com que as guias CMD elevadas se pareçam
para você?

A segurança é um ponto discutível se ninguém quiser usar sua ferramenta...

Você deve apenas criar um comando sudo para o Windows que funcione tanto no cmd.exe quanto no powershell. Isso me pouparia o trabalho de ter um atalho para ambos configurados para serem executados como administrador.

Para sua informação, escrevi um sudo for windows , chamado gsudo : https://github.com/gerardog/gsudo

Ele suporta a elevação de comandos cmd / powershell / pwsh ou todo o shell. É fácil de instalar e usar e deve se parecer com o *nix sudo original. Existem outras implementações sudo disponíveis, mas IMHO, gsudo é a mais versátil e fácil de usar.

Você pode usá-lo, por exemplo, para criar um perfil WT que chame gsudo cmd / gsudo pwsh ou gsudo WhateverShell para iniciar guias elevadas. Instale gsudo e adicione um perfil WT:

    {
      "hidden": false,
      "name": "PowerShell Core elevated",
      "commandline": "gsudo.exe pwsh"
    }

É um aplicativo cliente-servidor C# que atua como cliente quando não elevado e se inicia elevado como servidor. Ambas as instâncias se comunicam por meio de pipes nomeados seguros. Outros sudos do Windows em estado selvagem são principalmente como scripts 'runas' do PowerShell que abrem uma nova janela, mas ser um aplicativo completo me permitiu adicionar muito mais recursos.

Eu li o tópico e a segurança de um comando sudo foi discutida e alguns pontos válidos são feitos. Tomei todas as medidas de segurança que pude pensar e estou aberto (e planejando) para introduzir mais delas. Neste ponto, deve ser tão seguro/inseguro como se você abrir uma sessão PS de administrador remoto ou se você fizer ssh root@server de um console não elevado. (por exemplo, vulnerável a pressionamentos de tecla ou quebra de tela e corrija-me se estiver errado, mas meu entendimento é que * nix sudo também é vulnerável dessa maneira). Há também o cache de credenciais, que reduz a quantidade de popups do UAC durante uma sessão de 5 minutos (inspirado no *nix sudo), que claramente é um vetor de ataque, que pode ser desabilitado via config. Para aqueles preocupados com a segurança, estou planejando adicionar uma maneira muito fácil de aprimorá-la (desativando recursos como o cache de credenciais) com um comando simples ou por meio de uma configuração de registro/política de grupo empresarial.

Um ponto interessante feito neste comentário é que a Microsoft não pode se dar ao luxo de "aceitar riscos para conveniência do usuário". Se essa é a palavra final do MS, pelo menos isso parece uma solução decente (totalmente funcional), e todos os comentários/ problemas ou ideias sobre como melhorar a segurança são bem-vindos.

Não pode ser algo que eu tenha que instalar que não seja oficialmente suportado. Mata qualquer capacidade de usá-lo em um ambiente corporativo.

Então @hparadiz você teria que esperar até que uma nova versão do Windows fosse lançada com um novo design de segurança que permitisse um sudo oficial (ou guias de elevações mistas) sem riscos de segurança. Parece que não vai acontecer em breve. Sua melhor chance é esperar até que todo o WT possa ser lançado como administrador, rastreado em #4217, provavelmente lançado mais cedo.

Encontrei um bom hack em um blog:

http://nuts4.net/post/windows-terminal-run-as-admin

@gerardog você tem um balde de colher por gsudo ? ou é em um dos conhecidos? Estou atualmente em uma caixa linux, então não posso verificar.

@fluffynuts Está no repositório principal do scoop. Então, basta 'scoop install gsudo'. Outros métodos de instalação também estão listados em https://github.com/gerardog/gsudo . Mas vamos manter esta discussão no tópico WT. 😉

Pergunta em aberto: se é um risco de segurança misturar guias elevadas e não elevadas, esse risco está presente no ConEmu ? Porque ele pode fazer exatamente isso. Ou o ConEmu está implementando esse recurso de uma maneira diferente do que você faria no Terminal? E mais amplamente, eu observaria que muitos dos recursos solicitados aqui (neste segmento e outros) já existem em outros terminais, sendo o ConEmu apenas um exemplo, então quando os desenvolvedores do Terminal sugerem que esses recursos nunca seriam implementados ou não implementados para muito tempo, você está apenas confirmando implicitamente que não devemos usar o Terminal.

se não confiássemos em APIs que só existem em 1903, não precisaríamos de 1903.

@DHowett-MSFT Existe alguma documentação pública disponível sobre quais APIs são e por que são necessárias? Porque como observador externo, quando vejo essa decisão e a decisão de usar UWP, não vejo o valor agregado. Só vejo obstáculos para adicionar o que muitos usuários corporativos consideram ser uma funcionalidade básica.

@dadpolice Consulte https://github.com/microsoft/terminal/issues/632#issuecomment -518888895 para saber o que o ComEmu faz.

Eu pensei que "UAC não é uma barreira de segurança" de acordo com a Microsoft? Foi tratado como um no Vista. Então nos disseram que não era um e qualquer problema como esse era uma piada no Windows 7. Agora é um de novo hoje?

Talvez você precise revisar o design do File Explorer e a lista de permissões do UAC neste caso. :)

Ou apenas depende se é ou não uma desculpa para pegar um atalho no design de algo que os desenvolvedores normais não têm permissão para fazer (Explorador de Arquivos) ou não implementar um recurso essencial (neste caso)?

não implementar um recurso essencial (neste caso)?

Quero deixar claro - não estamos tentando _não_ implementar esse recurso. É certamente um recurso importante que _queremos_ implementar. É algo que estou enfrentando diariamente agora - ter uma segunda janela elevada é _ok_, mas não é _bom_.

Vai demorar um pouco para podermos projetar uma solução apropriadamente segura e também fazer o esforço de engenharia para realmente implementá-la. É algo que colocamos no quadro branco por um tempo esta semana.

@zadjii-msft

[...]
Não acho que planejamos oferecer suporte a guias elevadas e não elevadas mistas, porque é uma falha de segurança.
[...]

(como uma questão de vincular tópicos relacionados, #146)

Estranho que as pessoas estavam com a impressão de que o recurso não será implementado. sinal de sarcasmo

@kort3x Há uma diferença entre "No Plan" (também conhecido como não estamos prometendo) e não querer e fazer o que eles podem fazer, encontrar uma maneira de implementá-lo.

Como @zadjii-msft colocou:

Vai demorar um pouco para podermos projetar uma solução apropriadamente segura e também fazer o esforço de engenharia para realmente implementá-la. É algo que colocamos no quadro branco por um tempo esta semana.

Contanto que eles não tenham uma solução segura, eles não planejarão (também conhecido como promessa) oferecer suporte a guias de elevação mistas. Estou disposto a ser que o segundo que tiver uma solução segura, eles a adicionarão ao plano (embora eu não possa prometer nada).

Eu pensei que "UAC não é uma barreira de segurança" de acordo com a Microsoft? Foi tratado como um no Vista. Então nos disseram que não era um e qualquer problema como esse era uma piada no Windows 7. Agora é um de novo hoje?

Pelo que entendi é uma barreira de segurança se configurado como "Sempre notificar", caso contrário não é.

Bem, isso é decepcionante. Eu gosto do terminal (o que está dizendo muito, já que sou bastante apaixonado por ferramentas que não são do MS em geral), mas a incapacidade de elevar suavemente é uma barreira real para eu trabalhar mais neste sistema operacional.

LOL ok sim, eu posso ver como isso é confuso. Eu originalmente escrevi esse comentário dias depois que anunciamos, quando não havia um plano. Depois de alguns meses de discussão, certamente cheguei à ideia de que isso pode ser possível, com mais esforço. Vou atualizar o comentário para refletir isso. O @SamuelEnglard está certo, porém, é difícil _comprometer-se_ a fazer isso até que _sabemos_ que é possível fazer corretamente.

Isso é encorajador de ouvir. É possível estender esse entusiasmo a outras equipes, para que o #3581 possa realmente ser corrigido?

Seria bom se as guias pudessem ser processos diferentes (semelhante a como o chrome o gerencia) em primeiro lugar, porque eu não precisaria reiniciar todas as guias depois de agrupá-las bem apenas para obter um ambiente atualizado em um único guia cmd...
Uma vez que o Windows Terminal é apenas um gerenciador, ele pode ser executado em um modo não elevado enquanto ainda mantém os prompts de comando elevados. Isso seria legal. (bem, ter o wt executado elevado enquanto segura terminais não elevados também seria bom para mim)

@rapus95 tecnicamente as guias são, pois o "console" é um processo diferente. O Windows Terminal já é apenas um gerenciador

EDITAR (14 de fevereiro de 2020)
Ok, então este comentário não envelheceu super bem. Originalmente, não havia _nenhum_ plano para dar suporte a isso, já que não funcionaria com o único HWND que tínhamos. Estamos trabalhando no projeto de uma solução que _pode_ suportar isso no futuro, mas não podemos nos comprometer com nada até termos certeza de que podemos encontrar uma solução apropriadamente segura, que garanta que um processo com privilégios inferiores não possa conduzir um terminal de privilégio mais alto.

Além de alguns outros pontos, essa é a principal razão pela qual ainda estou usando ConEmu . E aposto que nunca vou.
https://conemu.github.io/ @Maximus5

Isso é tão estupido.

Vamos criar um novo terminal unificado para prompt de comando, powershell e bash para windows.
Posso executar cmd.exe como administrador?
Não.

Coisas idiotas como essa é o motivo pelo qual minha máquina de trabalho principal ainda é um Macbook.

@hparadiz Dê uma olhada no ConEmu :-D Não há problemas executando vários Shells como guias em UMA Janela; mesmo executando sessões elevadas do Powershell e cmd.exe, além das não elevadas.

@tmeckel temos certeza de que o conemu não tem as vulnerabilidades de segurança com as quais a equipe do terminal está preocupada? os usuários geralmente escolhem software menos seguro porque ele faz o que eles querem, mas por sua conta e risco.

@drdamour @tmeckel Faz. Fiz a mesma pergunta acima, ela foi respondida em outro tópico: https://github.com/microsoft/terminal/issues/632#issuecomment -518888895

Eu tenho sido bastante crítico do Terminal até agora, mas para ser justo, ConEmu e ConsoleZ e outras ferramentas semelhantes já existem. Há pouco valor na Microsoft simplesmente copiá-los, mas há um grande valor em recriar esses recursos de maneira segura. Dito isso, ainda acho muito bobo construir um emulador de terminal como um aplicativo UWP somente para loja, especialmente agora que a Microsoft parece estar se afastando do UWP (por exemplo, o novo Edge é um aplicativo Win32).

Dito isso, ainda acho muito bobo construir um emulador de terminal como um aplicativo UWP somente para loja, especialmente agora que a Microsoft parece estar se afastando do UWP (por exemplo, o novo Edge é um aplicativo Win32).

Para ser claro, o Terminal não é apenas Store ( há .msix's disponíveis aqui ), nem é um aplicativo UWP. É um aplicativo Win32 usando UWP XAML como sua estrutura de interface do usuário.

@rapus95 tecnicamente as guias são, pois o "console" é um processo diferente. O Windows Terminal já é apenas um gerenciador

Bem, então, por que o ambiente não é atualizado para uma nova instância cmd? Eu sempre preciso abrir um novo Terminal do Windows que, de certa forma, reduz a usabilidade geral de ter várias guias ...

@rapus95 enquanto eu não tenho certeza (eu teria que vasculhar o código), tenho certeza de que cada subprocesso é iniciado com o ambiente de seu pai e não um novo.

isso não parece fazer sentido para um gerenciador de terminal 🤔

@rapus95 Na verdade, é um bug que estamos rastreando aqui: # 1125

Para ser claro, o Terminal não é apenas Store ( há .msix's disponíveis aqui ), nem é um aplicativo UWP. É um aplicativo Win32 usando UWP XAML como sua estrutura de interface do usuário.

Isso soa como UWP com etapas extras. Seja o que for que faz com que eu não possa clicar com o botão direito do mouse no Terminal e executá-lo como um usuário diferente, como posso com qualquer aplicativo Win32 normal, essa foi uma escolha estranha.

Não é um aplicativo UWP nem um aplicativo somente da loja.
Acontece que um dos métodos de distribuição é o Store, que requer um pacote UWP.
Somente quem instalou usando a loja não consegue Right click -> Run As Admin .
Desinstale e use o msix ou via scoop

Desinstale e use o msix ou via scoop

Ou chocolatey .

@gerardog eu não disse executar como administrador, eu disse executar como usuário diferente.

Shift + Right Click não funciona para você?

(Observe que instalei usando scoop )

Não. Instalei usando o pacote msix e essa opção não existe.

Instalei como chocolatey e também não executei como administrador

Para ser claro, o Terminal não é apenas Store ( há .msix's disponíveis aqui ), nem é um aplicativo UWP. É um aplicativo Win32 usando UWP XAML como sua estrutura de interface do usuário.

Isso soa como UWP com etapas extras. Seja o que for que faz com que eu não possa clicar com o botão direito do mouse no Terminal e executá-lo como um usuário diferente, como posso com qualquer aplicativo Win32 normal, essa foi uma escolha estranha.

O mesmo aqui, eu tentei o msix e o aplicativo da loja. Ainda não tenho a opção "Executar como usuário diferente".

Que tal deixar todas as guias elevadas com a cor de fundo vermelha para que fique óbvio que está elevado?

Eu prefiro ter isso configurável: cor de fundo, título da guia ...

https://github.com/gerardog/gsudo funciona bem como uma solução temporária

Talvez implemente algo como wt elevated que abra uma nova janela elevada com o shell atual com o mesmo ambiente.
EDIT: ou #3158 mas como nova janela e elevada

Eu não entendo por que você não copia do jeito que o Linux faz isso.

No meu entendimento ou no mundo Linux (corrija-me se estiver errado), os aplicativos de terminal (gnome-terminal, mate-terminal ...) não precisam ser elevados mesmo se você digitar su ou sudo e executar o comando como o usuário raiz. A única missão do aplicativo de terminal é executar um shell em um processo diferente (bash, ksh...) que é ou não elevado e redirecionar a entrada e a saída do shell para que possamos interagir com o shell.

Se você digitar "su" ou iniciar um comando com "sudo" em um terminal linux, ele não abrirá uma janela diferente.

@gabsoftware Não tenho certeza sobre a segurança disso mesmo no Linux. Também é possível enviar pressionamentos de tecla para janelas X no Linux, e meu palpite é que é possível enviar pressionamentos de tecla para clientes de terminal em execução em uma janela X, mesmo que o terminal em execução seja elevado com sudo ou su. Pode até ser possível enviar pressionamentos de tecla para janelas X elevadas, mas realmente não tenho certeza.

Para ser claro, o Terminal não é apenas Store ( há .msix's disponíveis aqui ), nem é um aplicativo UWP. É um aplicativo Win32 usando UWP XAML como sua estrutura de interface do usuário.

Isso soa como UWP com etapas extras. Seja o que for que faz com que eu não possa clicar com o botão direito do mouse no Terminal e executá-lo como um usuário diferente, como posso com qualquer aplicativo Win32 normal, essa foi uma escolha estranha.

O mesmo aqui, eu tentei o msix e o aplicativo da loja. Ainda não tenho a opção "Executar como usuário diferente".

Não consigo "Executar como um usuário diferente" clicando com o botão direito do mouse no bloco no menu Iniciar, mas posso se clicar com o botão direito do mouse em WindowsTerminal.exe

@gabsoftware Não tenho certeza sobre a segurança disso mesmo no Linux. Também é possível enviar pressionamentos de tecla para janelas X no Linux, e meu palpite é que é possível enviar pressionamentos de tecla para clientes de terminal em execução em uma janela X, mesmo que o terminal em execução seja elevado com sudo ou su. Pode até ser possível enviar pressionamentos de tecla para janelas X elevadas, mas realmente não tenho certeza.

Eu fiz alguns experimentos e agora tenho certeza da insegurança disso no Linux. Eu não sou um especialista em segurança, então não tenho certeza sobre as implicações disso (alguém?). Acontece que é muito fácil enviar pressionamentos de tecla para janelas X que acabaram de executar sudo e estão abertas a novos comandos sudo sem solicitar uma senha. Post aqui no blog, desculpem o plug vergonhoso...

Minha conclusão seria que, a menos que haja uma maneira de não permitir o envio de pressionamentos de tecla para janelas de elevação mista, isso deve ser implementado apenas como uma opção para usuários dispostos a aceitar o risco (sinais de aviso grandes e gordos, etc.).

Como observação lateral, como o teclado na tela do Windows envia pressionamentos de teclas para janelas elevadas?

Eu lancei gsudo v0.7 e é relevante para este tópico:

EDIT: Por contexto: gsudo é um sudo para windows e permite elevar um comando simples ou um shell no console atual. Quando invocado de um Cmd/Pwsh dentro do WT, ele eleva a guia. Além disso, você pode editar seu perfil, nomeá-lo 'Elevated Powershell' e alterar seu comando para gsudo Powershell e voilá, você tem um perfil de guia elevado. Veja aqui .

Mas como o gsudo, ou qualquer sudo para windows, salta sobre o isolamento do UAC, ele foi rotulado como 'inseguro'. O que se segue é uma solução mais complicada que permite fazer elevações mistas de guias, mantendo a segurança. /END EDIT

gsudo agora pode iniciar aplicativos com qualquer nível de integridade. Por exemplo, podemos iniciar Windows Terminal com nível de integridade MediumPlus , isso significa um modo 'semi-elevado': sem direitos de administrador, mas isolado, inalcançável de outros processos regulares (Integridade média). (aparecerá um pop-up do UAC)

Então, o primeiro passo deve ser sempre lançar o WT com: gsudo -i MediumPlus WT
(Você pode alterar seu atalho WT). Isso protege o WT de processos maliciosos, screen-scrapping, sendkeys, injeção de dll, etc.
(EDIT: se não funcionar use: gsudo -n -i MediumPlus cmd /c cmd /c start wt )

Então você pode usar gsudo com segurança dentro do WT para elevar comandos, ou até mesmo criar um perfil elevado com: "commandline": "gsudo cmd.exe" em profiles.json

Minha conclusão seria que, a menos que haja uma maneira de não permitir o envio de pressionamentos de tecla para janelas de elevação mista... isso só deve ser implementado como uma opção para usuários dispostos a aceitar o risco (grandes sinais de aviso etc.).

Feito e feito. (Adicionei avisos de segurança ao gsudo).

Além disso, como aprendi que, se o usuário estiver invocando gsudo de um processo de integridade regular/médio , o cache de credenciais do gsudo (o recurso para mostrar menos pop-ups do UAC) nunca poderá ser totalmente protegido ... cache deve ser explicitamente habilitado via gsudo cache on/off ou gsudo config cachemode auto .

Acontece que "Changing your WT shortcut" não é nada trivial: Dado o modelo MSIX/AppStore, você encontrou #4217 e #4459.

O script powershell a seguir soluciona esses problemas para criar um atalho do Windows Terminal na área de trabalho e o associa à tecla de atalho Ctrl+Alt+T:

$shortcutPath = [Environment]::GetFolderPath("Desktop") + "\Windows Terminal Isolated.lnk"

# Use this if installed via Scoop. 
$wtPath = "$home\scoop\apps\windows-terminal\current\WindowsTerminal.exe"

# Use this if installed via Chocolatey or Ms Store
$wtPath = (Get-Command 'wt.exe').Path

$cmdPath = (Get-Command 'cmd.exe').Path
$gsudoPath = (Get-Command 'gsudo.exe').Path

$WshShell = New-Object -comObject WScript.Shell
$link = $WshShell.CreateShortcut($shortcutPath)
$link.TargetPath = $gsudoPath
$link.Arguments = "-n -i MediumPlus cmd /c cmd /c start $wtPath"

#Optional, set global Keyboard Hotkey
$link.Hotkey="Alt+Ctrl+T"

# Optional, download icon.
$icoPath = [IO.Path]::GetDirectoryName($wtPath) + "\wt.ico"
Invoke-RestMethod -Method Get -Uri "https://raw.githubusercontent.com/microsoft/terminal/master/res/terminal.ico" -OutFile $icoPath
$link.IconLocation="$icoPath,0"

$link.Save()

Depois de iniciar o WT como MediumPlus (ou seja, Ctrl+Alt+T), você pode usar gsudo conforme mencionado [acima] (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) para elevar comandos em que AFAIK deve ser seguro.

Minha solução para isso é usar o _Sudo for Windows_ de Luke Samson . A configuração do perfil é:
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
Ao iniciar uma nova guia com esse perfil, o UAC aparece e você acaba em um Powershell Core elevado. Também funciona com qualquer outro terminal.
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
Se você não usa scoop , tenho certeza que o conceito pode ser extraído e usado de forma independente. Confira o código-fonte aqui: https://github.com/lukesampson/psutils/blob/master/sudo.ps1

Estou usando a solução alternativa schtasks para executar o Windows Terminal como administrador e ignorar o UAC:

1. Inicie o Agendador de Tarefas.
2. Crie uma nova tarefa. Dê um nome e marque a caixa de seleção "Executar com privilégios mais altos".
   

3. Na guia Ações, selecione para iniciar um programa: wt

4. Na guia Configurações, certifique-se de que "Permitir que a tarefa seja executada sob demanda" esteja marcada e desmarque a caixa de seleção "Parar a tarefa se estiver em execução por mais tempo que".

5. Crie um atalho clicando com o botão direito do mouse na área de trabalho e selecione Novo -> Atalho e digite schtasks.exe /run /TN "{task name}"
   
6. Opcionalmente, altere o ícone de atalho e arraste-o para a barra de tarefas.

Parece que terei que ficar no cmder até que isso seja corrigido.

agora que há uma ideia de um plano supostamente, podemos obter os documentos
atualizado para não dizer mais que não há plano atual?

https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md#starting -a-new-powershell-tab-with-admin-privilege

@drdamour Quando houver um plano, adoraria remover essa seção. No momento, porém, há apenas um plano para pesquisar uma maneira de fazer um plano. Assim que houver um plano real e uma maneira de fazê-lo com segurança, removerei essa seção.

O método descrito por @KMoraz funciona muito bem como solução alternativa por enquanto. Obrigado por postar isso.

Oi, gente,

Eu estava usando o ConsoleZ até descobrir este ontem.
O ConsoleZ possui alguns recursos e um deles é iniciar uma nova guia como administrador usando o UAC (aparece a caixa de diálogo do UAC).
Acho muito útil porque você não precisa tirar as mãos do teclado para abrir uma nova aba elevada.

E se fosse uma configuração dentro da configuração do perfil? É assim que é feito no ConsoleZ.

Olá a todos,

Encontrei outra solução alternativa de atalho que é simples e funciona muito bem para quem precisa inserir credenciais de administrador local ao executar qualquer coisa como administrador.

Este link explica, mas precisa de um caminho completo para a referência wt.exe:
http://nuts4.net/post/windows-terminal-run-as-admin

Minha string de atalho completa é: C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

ATUALIZAÇÃO 21 de maio de 2020:
O acima costumava funcionar antes da versão 1.0.1401.0.

Veja também este novo problema: https://github.com/microsoft/terminal/issues/6013

Agora, o clique em Crtl-Shift também NÃO funciona quando você precisa elevar com uma conta de administrador local.

Veja a captura de tela de erro abaixo que recebo depois de ser solicitado duas vezes para permissões de elevação:

Para obter informações, o imho gsudo é perfeito para isso, thx https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

Minha configuração tem apenas este perfil para ganhar privilégio:

            {
                "name": "Admin Powershell",
                "commandline": "cmd.exe /c gsudo powershell.exe",
        "titleText": "Admin Powershell",
                "icon": "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png"
            },

Para mim, a maneira mais fácil de abrir o Windows Terminal como administrador é fixá-lo como o primeiro item na barra de tarefas. Então Win+Ctrl+Shift+1 abre como admin

Para mim, a maneira mais fácil de abrir o Windows Terminal como administrador é fixá-lo como o primeiro item na barra de tarefas. Então Win+Ctrl+Shift+1 abre como admin

Realmente muito conveniente, mas isso só funciona para contas que são membros do grupo Administradores.

Se você estiver atuando como administrador de outra pessoa, não poderá executar o Windows Terminal como seu usuário (administrador) da conta dela.

Acho que seria bom ter uma configuração de guia para executar o cmd como administrador, nem tudo.

Acho que seria bom ter uma configuração de guia para executar o cmd como administrador, nem tudo.

Conforme explicado em outro lugar aqui, isso não é possível com o design atual.

existe um sinalizador que pode ser usado para executar como administrador? Então poderíamos apenas criar um atalho para ele.

Se você fixar o Windows Terminal na barra de tarefas, poderá iniciá-lo _elevado_ usando Ctrl+Shift+clique.

Isso fará o mesmo que clicar com o botão direito do mouse no ícone, clicar com o botão direito do mouse em "Terminal do Windows", seguido de "Executar como administrador".

Observação: sendo o Windows Terminal um aplicativo da Store, você não pode executá-lo como _outro usuário_.

Eu adoraria ver a capacidade de ter "guias de nível de integridade misto" no Windows Terminal, com o nível de integridade como uma opção em cada perfil. Isso é principalmente uma conveniência no meu trabalho normal de sysadmin/devops para minimizar as interrupções do fluxo de trabalho e a troca de contexto.

Eu encontrei uma alternativa simples que funciona para mim por enquanto. Isso não aborda todos os cenários apresentados aqui por outros usuários. Não depende de aplicativos de terceiros, arquivos de atalho, combinações de teclas ou tarefas agendadas. Não requer a identificação do local do executável do Windows Terminal. Ele apenas cria uma entrada separada na lista de perfis do Windows Terminal que inicia uma segunda instância do Windows Terminal elevada. Isso aciona um prompt do UAC uma vez. Eu só uso isso se e quando eu precisar de elevação.

O resultado são dois terminais Windows. Qualquer coisa em um é padrão e qualquer coisa no outro é elevada. Para mim, este é um nível aceitável de interrupção e mudança de contexto. O Terminal Windows elevado também precede cada título de guia com "Administrador:", o que dá uma boa confirmação visual da diferença.

Edit: Eu tenho o Powershell 7 instalado,

            "name" : "Launch Windows Terminal Elevated",
            "commandline" : "pwsh.exe -command Start-Process -Verb RunAs wt.exe"

@IarwainBen-adar, me lembro de ter lido recentemente nos novos documentos que você não pode usar o item commandline e o item source juntos. Funciona como esperado sem o item source ?

Tentei o código dele e não consigo nem fazer o novo item aparecer no pull
menu para baixo.

@shem-sargent desculpe por isso, eu deletei meu comentário aqui porque a declaração source estranha era realmente o problema. Embora, agora que tenho a entrada do menu funcionando, infelizmente ainda não consigo iniciar uma instância elevada do Windows Terminal - estou enfrentando o problema #3145 com uma falha de The file cannot be accessed by the system.

@IarwainBen-adar Desculpe, não consigo reproduzir #3145. Caso contrário, eu tentaria solucionar problemas do meu lado.

fixe na barra de tarefas e shift + clique com o botão direito

Saudações @LordFPL e, claro, @gerardog , eu nunca tinha ouvido falar de gsudo (https://github.com/gerardog/gsudo para outros interessados) antes, mas isso torna as sessões elevadas uma brisa agora. Obrigado! Adicione-o ao objeto de perfil no arquivo de configurações ou apenas use o alias sudo como faria em um sistema Linux. Perfeito!

@zadjii-msft minhas desculpas, mas não entendo exatamente qual é o problema aqui. O Windows suporta manipulação e representação de token, é assim que funciona o runas, não é? usando gsudo de @gerardog , posso ter uma integridade baixa (er) hospedando um shell de integridade alta (er) ao mesmo tempo que qualquer outro shell de integridade de nível, seja powershell, pwsh, cmd ou qualquer shell wsl. Dos meus testes limitados, nenhum dos shells de integridade mais baixa pode depurar nesse shell de integridade mais alta. Qual é o obstáculo aqui para ter isso como um terminal embutido, ou ainda mais preferível no nível do sistema operacional, recurso?

@smokeintheshell https://github.com/microsoft/terminal/issues/632#issuecomment -519375707

Uma janela de baixa (er) integridade _recebendo entrada e canalizando-a diretamente para um processo de alta (er) integridade_ abre esse processo de alta (er) integridade para ser controlado por outras coisas de baixa (er) integridade no sistema.

Isso significa que um processo potencialmente malicioso precisa apenas de um movimento lateral no mesmo nível de privilégio para obter EoP.

@smokeintheshell #632 (comentário)

Uma janela de baixa (er) integridade _recebendo entrada e canalizando-a diretamente para um processo de alta (er) integridade_ abre esse processo de alta (er) integridade para ser controlado por outras coisas de baixa (er) integridade no sistema.

Isso significa que um processo potencialmente malicioso precisa apenas de um movimento lateral no mesmo nível de privilégio para obter EoP.

sim, eu li essa explicação no início do tópico, mas não entendo por que é bom para Linux e provavelmente Mac, mas não é bom para Windows? Atualmente, o Windows protege a entrada para processos elevados de processos não elevados. Nesses problemas ou em um relacionado, alguém sugeriu que precisássemos de um processo separado por guia. Eu acho que esse já é o caso, pois cada guia tem seu próprio comando para executar (por exemplo: pwsh.exe). É porque eles são todos filhos do mesmo processo raiz em um HWND?

O terminal do Ubuntu sofre do mesmo problema com guias se eu:

• tem uma aba com su aberta
• tem uma aba onde eu já elevei com sudo e não preciso inserir meu PW novamente por política de configuração?

Ou a arquitetura do Ubuntu está de alguma forma reforçada contra ataques de injeção de entrada de processo cruzado?

O terminal do Ubuntu sofre do mesmo problema com guias se eu:

* have a tab with `su` open

* have a tab where I have elevated with `sudo` already and don't need to enter my PW again per configuration policy?

Ou a arquitetura do Ubuntu está de alguma forma reforçada contra ataques de injeção de entrada de processo cruzado?

Se você olhar para o meu comentário aqui , eu realmente reproduzi/explorei o problema no Linux. Ambos su e sudo são provavelmente igualmente "vulneráveis", pois você pode enviar pressionamentos de tecla para janelas de integridade inferior executando esses comandos. O tempo limite da senha do sudo (não ter que digitar sua senha no próximo comando sudo em 15 minutos), torna isso ainda mais fácil. Você pode fortalecer o Ubuntu desabilitando a extensão X necessária para o ataque. Não tenho certeza se isso é possível em um ambiente Wayland (o ataque e/ou o endurecimento).

Eu entendo completamente a decisão de não implementar guias de elevação mista, a menos que haja alguma maneira de desabilitar teclados virtuais e outros métodos de entrada de software.

Eu acho que esse já é o caso, pois cada guia tem seu próprio comando para executar (por exemplo: pwsh.exe). É porque eles são todos filhos do mesmo processo raiz em um HWND?

@kbirger Sim, existem processos separados para cada guia, mas todas as entradas de mouse e teclado ainda são enviadas para a janela do Windows Terminal (que é de baixa integridade) e, em seguida, roteadas para cada processo de shell por meio de fluxos de entrada padrão. É assim que todos os atalhos de teclado do Windows Terminal funcionam.

Gostaria de saber se é possível detectar se a entrada é forjada, por exemplo usando a API GetCurrentInputMessageSource . Não consigo encontrar muitas informações sobre esta API além do exemplo oficial, mas pela descrição deve ser capaz de identificar a fonte de entrada (hardware/de processos com uiAccess, principalmente software de acessibilidade/de processos sem uiAccess, talvez malicioso)

por que é bom para Linux e provavelmente Mac, mas não é bom para Windows?

Tenho certeza de que uma das razões é que a Microsoft está vendendo segurança como um recurso para outras grandes corporações ou governos.

Há também algumas outras razões que me vêm à mente sobre por que isso pode não ter sido um problema até agora:

• Por muito tempo, e por vários motivos (como "hackers" que não gostam do Windows e "todo mundo" que usa o Windows ^^), o Windows costumava ser o alvo principal (≈apenas) de todos os tipos de malware. Precisava de melhor segurança (protegendo janelas elevadas), enquanto outros não se importavam muito.
• Conforme explicado anteriormente nesta edição, não deveria ter sido possível para malware acessar facilmente seu host de console elevado no Windows, então é provável que poucos tenham investido nesse problema (não sou especialista em segurança, então não sei se alguns têm)
• O malware geralmente teve outras maneiras de se elevar do que tentar encontrar um prompt de comando elevado no sistema operacional de sua escolha
• Apenas desenvolvedores e administradores de sistema usam terminais (isso apenas reduz o alvo demográfico do ataque; governos e grandes corporações ainda são uma preocupação)

Agora, ao introduzir o recurso ingenuamente (como todos nós teríamos feito, tenho certeza 😄), você estaria introduzindo uma nova (enorme) falha em algumas instalações do Windows. Com o desenvolvimento sendo feito abertamente, você pode ter certeza de que todos os necessitados estariam cientes da falha e começariam a codificar contra ela.
A contramedida rápida é banir o Windows Terminal (e provavelmente todos os outros emuladores de terminal agora que a falha é pública), você pode dar adeus aos seus sonhos de usar o Windows Terminal em qualquer tipo de ambiente corporativo 😟

Ainda espero muito que uma versão segura desse recurso veja a luz do dia 🤞

Entendo. Obrigado pelas explicações!

Como observação lateral, como o teclado na tela do Windows envia pressionamentos de teclas para janelas elevadas?

@mrwensveen AFAIK existem três maneiras de enviar entradas para janelas elevadas:

1. Eleve-se. No entanto, você ainda não pode enviar entradas para processos do sistema (por exemplo, Gerenciador de Tarefas, caixa de diálogo UAC, tela de login).
2. Registre um serviço do Windows. Agora seu programa é executado como SYSTEM para que você possa fazer o que quiser. Já vi alguns programas de acesso remoto fazerem isso.
3. Declare o sinalizador uiAccess , assine digitalmente seu binário, instale em um local que não seja gravável para o usuário atual. É um "backdoor" para softwares de acessibilidade, permitindo que eles leiam/gravem quaisquer outros programas (incluindo processos do sistema) e exibindo em cima de qualquer outra janela (incluindo o Secure Desktop, onde os pop-ups do UAC são exibidos e a tela de login), tudo sem ser elevado. Consulte https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

Teclado na tela (osk.exe), Narrator.exe (e talvez outros leitores de tela) todos usam o método 3.

(Uma captura de tela mostrando o manifesto do programa incorporado de osk.exe com uiAccess=true )

Parece que o sinalizador uiAccess também pode proteger o programa de ser acessado por outros programas de baixa integridade (apesar de ainda ser executado sem elevação), talvez possamos usar esse "recurso" para proteger o WT?

@yume-chan Legal, isso é muito interessante, obrigado! Os programas uiAccess podem enviar pressionamentos de tecla para outros programas uiAccess ? Ainda queremos que o OSK possa interagir com o terminal do Windows, e se isso significa que outros programas devem pelo menos ser assinados antes de poder enviar entrada para o terminal do Windows, isso é uma barreira alta o suficiente?

Os programas uiAccess têm permissão para enviar pressionamentos de tecla para outros programas uiAccess?

@mrwensveen Sim, programas com privilégio uiAccess podem acessar uns aos outros.

Eu prefiro a maneira da API GetCurrentInputMessageSource (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562) porque esse não é o uso pretendido uiAccess . Além disso, com a API, ainda podemos permitir que programas de baixa integridade enviem pressionamentos de tecla para guias não elevadas, mas não para guias elevadas.

Pequena solução que fiz aqui:

Eu instalei PowerToys que tem alguns recursos interessantes. Uma delas é mostrar os atalhos do windows e descobri que ao pressionar Win + número, ele abre o app na barra do windows correspondente ao número que aparece na barra.

Então, eu coloquei o terminal na barra como o primeiro ícone
.

Quando pressiono Win + 1, o terminal abre.

Quando pressiono Win + Ctrl + Shift + 1, ele abre elevado.

Colocarei minha configuração de terminal e perfil do powershell aqui também se você quiser obter os recursos de mostrar o ambiente git branch e conda no prompt e o usuário em vermelho se for um terminal elevado ...

Isso existe desde pelo menos o Windows 7; não é uma coisa de PowerToys.

@Firehawke Sim, acabei de descobrir por causa do PowerToys ... não é necessário.

Aqui está um perfil para iniciar elevado que funciona na Windows Store e tem um ícone adequado:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

EDIT: Crédito para @glooms , @shem-sargent, @LordFPL e @Firehawke por diferentes componentes deste trecho. Como este comando chama pwsh.exe , parece que algumas pessoas encontraram #4228 (um erro 0x80070002 ao iniciar) com isso devido a variáveis ​​​​de ambiente PATH corrompidas ou binários estranhos em seu caminho chamado powershell.exe ou pwsh.exe . @zurkz corrigiu isso referenciando powershell.exe , mas não acho que seja confiável agora. #6684 resolve esse problema para o Windows Terminal, e você encontrará uma versão corrigida abaixo, seguindo essa solução, que não deve ter esse problema.

Aqui está um perfil para iniciar elevado que funciona na Windows Store e tem um ícone adequado:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g Isso funciona bem! Obrigada.

Aqui está um perfil para iniciar elevado que funciona na Windows Store e tem um ícone adequado:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g ❤💯

Aqui está um perfil para iniciar elevado que funciona na Windows Store e tem um ícone adequado:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@anyone Perdoe minha ignorância, isso é descartado na configuração da Windows Store? Se sim, alguém pode postar o caminho? Se não, onde esse bad boy deveria morar?

TIA!

@Kazamario
Ele vai no arquivo settings.json do Terminal do Windows, na seção de perfis.

Causa um erro: 0x80070002 ao iniciar. pwsh 7.1.

Eu mudei para:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

e o UAC solicitado a elevar as permissões.

Eu mudei para:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

e o UAC solicitado a elevar as permissões.

isso funcionou muito bem para mim. Obrigado!

Aqui está como iniciar o Windows Terminal elevado se ele foi fixado em Iniciar.
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@narfanar Parece que você encontrou #4228, onde o Windows Terminal emite o erro 0x80070002 na inicialização quando a variável de ambiente PATH está bagunçada ou outros binários estão flutuando no caminho chamado powershell.exe ou pwsh.exe . Eu não acho que o snippet de @zurkz realmente corrige isso, pois apenas muda os problemas potenciais de pwsh.exe para powershell.exe . #6684 corrigiu isso para o WT, então aqui está um trecho ajustado para essa solução:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

console-z faz isso bem

Observe que o Cmder possui esse recurso, que é incrivelmente útil. Adoraria vê-lo implementado no Windows Terminal. Mesmo que tenha que lançar uma janela separada para as guias Admin ou algo assim.

meu perfil padrão está definido para bash em vez de powershell, e eu gostaria de mantê-lo assim. o trecho acima funciona muito bem, mas adoraria poder fazê-lo lançar um novo terminal elevado com o perfil do powershell carregado. Eu passei umas 3 horas tentando descobrir isso (não sou um grande fã de / tenho muita experiência com powershell) e não consigo descobrir - por favor, ajude. parece que há alguma combinação de aspas simples, aspas duplas, escape, espaços, novas linhas, que podem fazer com que funcione, mas não consigo iniciar o processo e a lista de argumentos para fazer o que quero. reduzi-o a:

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
isso funciona em um arquivo .ps1 se eu executá-lo sozinho, recebo um novo terminal elevado do Windows com o perfil powershell carregado. mas não funciona no parâmetro de linha de comando de settings.json, não importa como eu tente desmontá-lo, chamando explicitamente argumentlist em vez de usar cmd /c, várias formas de escape e uso de citações, etc.

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
não funciona. o melhor que posso fazer é fazer com que ele lance um híbrido estranho do que eu quero. vou carregar uma janela "Administrador: Ubuntu", que se parece com o meu perfil bash, mas na verdade está executando o powershell. fonte errada e tudo. se eu usar essa janela para abrir uma nova guia do powershell, ela será elevada conforme desejado. quando é assim, posso colocar o lixo que quiser na parte "Windows PowerShell" do carregamento do perfil e recebo exatamente o mesmo comportamento, então sei que não está realmente tentando carregar o perfil que estou passando.

Então, estou tendo um problema ao tentar ainda executar isso como elevado, fiz todas as opções listadas acima e recebo o erro "Não é possível encontrar o arquivo" ou isso.

Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At line:1 char:1
+ Start-Process -Verb RunAs shell:appsFolder\\Microsoft.WindowsTerminal ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Alguém mais com o problema ainda ou não conseguiu fazer com que eles funcionem bem?

meu perfil padrão está definido para bash em vez de powershell, e eu gostaria de mantê-lo assim.

Eu também. Eu corro o WSL na maioria das vezes, mas de vez em quando eu preciso rodar o PS elevado, e eu gostaria de fazer isso em uma aba do novo WT.

Também não consegui fazer nenhum dos exemplos funcionar - mesmo corrigindo meus caminhos de arquivo. Encontrei e instalei o gsudo que pode elevar a guia atual ou ser usado como um perfil para abrir uma guia elevada na mesma janela. Não tenho certeza se as soluções acima começaram em uma nova janela (algumas tentativas que fiz antes de usar gsudo só começariam em uma nova janela). Ele abrirá um pop-up do UAC.

Este é o perfil que estou usando:

{
    // Elevated Powershell using gsudo
    // https://github.com/gerardog/gsudo
    "name": "Elevated PowerShell",
    "commandline": "powershell.exe gsudo powershell.exe -nologo",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png",
    "suppressApplicationTitle": true
}

Estou usando supressApplicationTitle para que o título da guia não exiba Administrator: como redundante com Elevated .

@ayfine Se https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 realmente não estiver funcionando para você, você poderia enviar uma transcrição dos erros exatos / comportamento inesperado que você está obtendo com essa configuração? (Certifique-se de adicionar uma configuração extra, como suppressApplicationTitle , em etapas tão pequenas quanto possível, para que, se alguma configuração estiver quebrando o WT, seja mais fácil dizer onde e quando está acontecendo.)

Se quaisquer outras configurações aqui forem um pouco além da vinculada para você, detalhes sobre como elas estão quebrando também serão apreciados.

@bb010g Não estou encontrando nenhuma mensagem de erro - minhas desculpas por não ser mais preciso em minha resposta. Ao usar https://github.com/microsoft/terminal/issues/632#issuecomment -663686412, encontrei o problema do Windows Terminal carregando meu shell WSL Ubuntu (meu padrão). Eu tinha entendido isso originalmente para significar que não estava funcionando corretamente, mas vejo agora que nessa nova janela, se eu iniciar uma nova guia Powershell (perfil padrão), ela é de fato elevada. Independentemente disso, tanto abrindo uma nova janela quanto tendo que iniciar uma nova guia dentro dela, não é mais fácil do que executar um processo elevado no meu menu Iniciar. O que descrevi na minha resposta original fornece o comportamento exato que eu estava imaginando.

@ayfine - e copiei seu exemplo gsudo. Essa é uma solução boa o suficiente até que algo embutido seja codificado. Obrigado.

@ayfine Eu tentei a coisa do gsudo, mas é uma experiência horrível. Qualquer tipo de conclusão de TAB parece ser interrompido e os caracteres Unicode (não ASCII) parecem não ser exibidos. Acho que é algum tipo de processo que redireciona a entrada e a saída e faz um trabalho terrível nisso. Acho que a solução com uma janela separada funciona melhor.

Se você estiver tendo problemas com o gsudo, informe-os ao @gerardog e não neste tópico. Cada mensagem neste tópico (incluindo esta; desculpe!) envia e-mails para centenas de assinantes.

Vou bloquear este tópico para outros comentários não mantenedores, pois estamos chegando ao ponto em que mais comentários não estão levando a discussão adiante de forma significativa.

Registre novos problemas se tiver dúvidas que não são abordadas aqui.