Terminal: [Question] Configuration du profil du terminal Windows pour qu'il se lance toujours en mode élevé

Cr√©√© le 9 mai 2019  ¬∑  212Commentaires  ¬∑  Source: microsoft/terminal

Salut! Existe-t-il un moyen de configurer un profil pour que le commandLine qu'il lance démarre toujours avec des autorisations élevées (administrateur) ?

Actuellement, vous pouvez lancer l'intégralité de l'application en tant qu'administrateur, mais chaque commandLine s'exécute en tant qu'administrateur, ce qui n'est pas idéal.

Area-Settings Issue-Feature Product-Terminal

Commentaire le plus utile

Il n'y a pas. Je ne pense pas que nous prévoyons de prendre en charge des onglets mixtes élevés et non élevés, car c'est un peu une faille de sécurité.

Oui, je sais que sudo est une chose, mais nous avons eu de nombreuses discussions avec l'√©quipe de s√©curit√© au sujet de la cr√©ation d'un sudo pour Windows. Le probl√®me principal est d√Ľ au fait que tout processus non √©lev√© peut envoyer des frappes √† n'importe quelle autre fen√™tre non √©lev√©e.

Si vous aviez une ligne de commande élevée s'exécutant dans une fenêtre non élevée, un acteur malveillant non fiable pourrait exécuter une attaque d'élévation de privilèges en pilotant les fenêtres non élevées qui exécutent la ligne de commande élevée.

(pour ce qui est de lier des discussions connexes, #146)


MODIFIER (14 février 2020)
D'accord, donc ce commentaire n'a pas tr√®s bien vieilli. √Ä l'origine, il n'y avait _aucun_ plan pour supporter cela, car cela ne fonctionnerait pas avec le seul HWND que nous avions. Nous travaillons √† la conception d'une solution qui _pourrait_ prendre en charge cela √† l'avenir, mais nous ne pouvons rien nous engager tant que nous ne sommes pas s√Ľrs de pouvoir proposer une solution s√©curis√©e appropri√©e, qui garantit qu'un processus √† privil√®ges inf√©rieurs ne peut pas conduire un terminal √† privil√®ges plus √©lev√©s.

Tous les 212 commentaires

Il n'y a pas. Je ne pense pas que nous prévoyons de prendre en charge des onglets mixtes élevés et non élevés, car c'est un peu une faille de sécurité.

Oui, je sais que sudo est une chose, mais nous avons eu de nombreuses discussions avec l'√©quipe de s√©curit√© au sujet de la cr√©ation d'un sudo pour Windows. Le probl√®me principal est d√Ľ au fait que tout processus non √©lev√© peut envoyer des frappes √† n'importe quelle autre fen√™tre non √©lev√©e.

Si vous aviez une ligne de commande élevée s'exécutant dans une fenêtre non élevée, un acteur malveillant non fiable pourrait exécuter une attaque d'élévation de privilèges en pilotant les fenêtres non élevées qui exécutent la ligne de commande élevée.

(pour ce qui est de lier des discussions connexes, #146)


MODIFIER (14 février 2020)
D'accord, donc ce commentaire n'a pas tr√®s bien vieilli. √Ä l'origine, il n'y avait _aucun_ plan pour supporter cela, car cela ne fonctionnerait pas avec le seul HWND que nous avions. Nous travaillons √† la conception d'une solution qui _pourrait_ prendre en charge cela √† l'avenir, mais nous ne pouvons rien nous engager tant que nous ne sommes pas s√Ľrs de pouvoir proposer une solution s√©curis√©e appropri√©e, qui garantit qu'un processus √† privil√®ges inf√©rieurs ne peut pas conduire un terminal √† privil√®ges plus √©lev√©s.

Semble raisonnable. Je pense qu'avoir quelque chose comme une combinaison de # 576 (Ouvrir en tant qu'administrateur dans la liste de raccourcis) et peut-être une sorte de raccourci clavier pour lancer une session d'administration du terminal résoudrait la plupart de mes problèmes ici.

Qu'en est-il d'avoir un terminal standard et élevé ouvert dans une seule fenêtre mais des onglets séparés ?

@mdtauk Je pense que cela rel√®ve malheureusement de la m√™me cat√©gorie. √Čtant donn√© que tous les onglets sont sous le m√™me HWND, le HWND racine est ce qui devrait √™tre √©lev√© pour emp√™cher les applications non √©lev√©es de piloter la fen√™tre.

Du point de vue de la s√©curit√© (en ignorant la conception de Windows Terminal, HWND √† racine unique, etc.), dans quelle mesure le terminal ex√©cute-t-il des onglets √† √©l√©vation mixte par rapport √† l'ex√©cution, par exemple, d'une instance PowerShell √©lev√©e √† c√īt√© d'une instance non √©lev√©e dans l'UX actuel ? Le fait que les applications de la console soient h√©berg√©es dans des onglets Terminal ne fait aucune diff√©rence pour moi...

Sur une note similaire: comment avoir une fen√™tre non √©lev√©e est-il plus s√©curis√© m√™me si j'ouvre une session PS distante o√Ļ je peux maintenant avoir des privil√®ges d'administrateur sur un serveur distant qu'un non-√©lev√© pourrait d√©sormais conduire. Pour moi, cela semble bien pire que d'obtenir un acc√®s administrateur local, donc je ne pense pas que l'ex√©cution d'un onglet en tant qu'administrateur soit diff√©rente de la communication √† distance / ssh vers d'autres serveurs. Dans les deux cas, je dois me sentir suffisamment √† l'aise avec mon syst√®me pour le faire. C'est une chose "je suis assez vieux et je comprends les risques".

Chaque fois que j'essaie d'ex√©cuter l'application Terminal avec un compte administrateur, faites un clic droit -> ex√©cuter en tant qu'administrateur, l'UAC appara√ģt deux fois et une erreur se produit en disant¬†:
"Windows ne trouve pas (chemin\WindowsTerminal.exe) Assurez-vous d'avoir tapé...".

Le chemin existe et l'application fonctionne correctement pour l'utilisateur non administrateur qui a créé l'application, mais l'autre utilisateur administrateur ne peut pas l'exécuter.
Si je me connecte à l'utilisateur administrateur, l'application du terminal n'est présente ni dans les paramètres ni dans le menu Démarrer, comme si elle n'avait jamais été installée sur le système.

Existe-t-il un moyen de créer l'application afin qu'elle s'installe pour tous les utilisateurs ? Ou la racine du projet doit-elle se trouver dans un répertoire non spécifique à l'utilisateur ?

@

Chaque fois que j'essaie d'ex√©cuter l'application Terminal avec un compte administrateur, faites un clic droit -> ex√©cuter en tant qu'administrateur, l'UAC appara√ģt deux fois et une erreur se produit en disant¬†:
"Windows ne trouve pas (chemin\WindowsTerminal.exe) Assurez-vous d'avoir tapé...".

Le chemin existe et l'application fonctionne correctement pour l'utilisateur non administrateur qui a créé l'application, mais l'autre utilisateur administrateur ne peut pas l'exécuter.
Si je me connecte à l'utilisateur administrateur, l'application du terminal n'est présente ni dans les paramètres ni dans le menu Démarrer, comme si elle n'avait jamais été installée sur le système.

Existe-t-il un moyen de créer l'application afin qu'elle s'installe pour tous les utilisateurs ? Ou la racine du projet doit-elle se trouver dans un répertoire non spécifique à l'utilisateur ?

Je vois le même problème se produire également.

Version Windows 18922.1000

D'accord, donc l'ex√©cution d'applications de magasin en tant qu'administrateur ou utilisateur diff√©rent ne fonctionne pas (par conception BTW). Beaucoup d'entre nous sont connect√©s (au PC) en tant que compte normal non √©lev√©. Nous ex√©cutons powershell/cmd/etc en tant qu'administrateur pour effectuer certaines t√Ęches.

Si le choix final est de déployer cette application dans le magasin Windows, cela ne me sert à rien sans un moyen d'ouvrir des onglets élevés. Mes 2 centimes.

"Inutile" est peut-√™tre un peu dur, mais en effet, nous avons besoin d'un moyen d'utiliser le nouveau terminal √† la fois pour les applications/shells de console non √©lev√©s et √©lev√©s. Et pour moi, le meilleur UX serait de prendre en charge un m√©lange d'onglets √©lev√©s et non √©lev√©s dans la m√™me instance de terminal Windows. Moins pr√©f√©rable¬†: prendre en charge z√©ro √† plusieurs (g√©n√©ralement une) instances √©lev√©es (chacune avec un √† plusieurs onglets) aux c√īt√©s de z√©ro √† plusieurs (g√©n√©ralement une) instances non √©lev√©es.

ConEmu est capable de mélanger des onglets élevés et non élevés dans la même fenêtre. Est-ce que quelque chose comme ça ne peut pas être fait ici?

Pourrions-nous avoir un Terminal surélevé pour lancer des onglets non surélevés ? J'ai encore besoin de lancer une élévation MAIS je peux ouvrir un nouvel onglet "protégé".

Si nous voulons être très spécifiques à Windows et ignorer d'autres plates-formes qui pourraient éventuellement voir Terminal, l'utilisation de conteneurs Windows ou de processus virtualisés pourrait peut-être aider certains à résoudre ce problème. Personnellement, je suis très bien avec la solution actuelle, mais faire en sorte que les applications de la console s'exécutent en tant que processus isolés par défaut ne serait pas une mauvaise idée du point de vue de la sécurité.

L'élévation mixte dans une fenêtre est un must, du moins pour moi.
Pourrait-il s'agir d'une fonctionnalité facultative à basculer dans les paramètres ?

@pratnala Avec ConEmu, √ßa ne fait que _ressembler_ √† faire √ßa, mais √ßa ne fait pas vraiment √ßa du tout. Les "onglets" √©lev√©s et non √©lev√©s ne sont que des vues dans deux fen√™tres/processus racine compl√®tement s√©par√©s et isol√©s. Il le fait en grattant le contenu des fen√™tres entre autres et les assistants d'√©l√©vation proxy/courtier, etc. Bien s√Ľr, c'est techniquement possible, mais ce que fait ConEmu est en fait un peu dangereux. C'est une chose pour un programme tiers de faire cela et de faire en sorte que les gens acceptent le risque en t√©l√©chargeant ConEmu, mais c'en est une autre pour Microsoft d'approuver officiellement cela en le faisant lui-m√™me. Si je veux cacher mes cl√©s de porte d'entr√©e sous le paillasson, alors tr√®s bien - c'est mon risque stupide √† prendre. Mais que se passe-t-il si chaque porte que vous achetez met un jeu de cl√©s sous le paillasson ?

Mais voyez, je développe en C++ (et C#, PowerShell, Ruby, Python, GoLang, à peu près tout ce qui se présente à moi.) J'ai installé ConEmu et TakeCommand, ainsi que mingw. Je sais dans quel sens tenir les ciseaux pendant que je cours.

PowerShell _est_ une faille de s√©curit√©. Un outil d'automatisation tr√®s utile, permettant toutes sortes d'acc√®s inattendus. Et ce que nous demandons (modes mixtes) est certainement plus s√Ľr que l'alternative (tous √©lev√©s.) Vraiment, ce (terminal) est un outil puissant pour les utilisateurs exp√©riment√©s, dont la plupart comprennent probablement extr√™mement bien le paysage de la s√©curit√©... et comprennent compromis pragmatique.

La confiance zéro ne fonctionne que lorsqu'elle n'est pas débilitante.

@robomac Si nous pouvions convaincre l'équipe de sécurité (qui nous a dit à plusieurs reprises de ne même pas s'aventurer à distance près d'une élévation mixte) que seules les personnes qui savent tenir leurs ciseaux correctement et ne pas courir avec eux _utiliseraient_ ce projet, nous le ferions probablement. Je ne sais pas si j'y crois moi-même. Voici pourquoi:

Comme si ce n'√©tait pas le cas, si Terminal s'ex√©cute en √©l√©vation mixte (d'un h√īte Medium-IL √† un client High-IL), il peut toujours √™tre forc√© de recevoir des entr√©es de toute autre personne s'ex√©cutant en tant que cet utilisateur. M√™me si la personne derri√®re le clavier est une sainte et ne s'√©l√®ve que pendant les dix secondes dont elle a besoin pour s'√©lever, _toute application ex√©cut√©e sous son compte d'utilisateur peut se faire passer pour l'administrateur sans invite d'√©l√©vation suppl√©mentaire_. Probablement enti√®rement non d√©tect√©, m√™me.

@ DHowett-MSFT Je vous remercie d'avoir répondu. Vous partez du principe que nous autorisons l'exécution de processus malveillants de toute façon. Nous restreignons les autorisations en dehors des mantras "Best Practices" que nous faisons avec notre pose de chien tête en bas tous les matins, mais si vous craignez vraiment que quelques heures, même, d'accès au terminal élevé vous mettent en danger _sur votre propre système qui vous développez sur_ ...

  1. Vous ne devriez pas exécuter Terminal et
  2. Vous devriez essuyer et recommencer.

Je vous accorde qu'un chercheur de virus (informatiques) ne devrait pas risquer cela dans un chemin vectoriel... mais même au début, nous les avons mis en bac à sable dans des machines virtuelles. Mais "Terminal" n'est pas pour vos proches peu avertis ; c'est un outil électrique.

Il existe une manière standard de gérer le risque. Apporté à vous par le monde du navigateur. Lorsque vous accédez aux drapeaux avancés, vous recevez un avertissement, à peu près, "Voici des dragons". (Je pense que c'est précisément cela dans Pale Moon... qui est le navigateur de sécurité hard-core sérieux.) Ajoutez l'avertissement (non-UAC, supplémentaire), mais laissez l'utilisateur décider.

Une autre question : est-ce que deux sessions distinctes de Terminal, l'une élevée, l'autre non, se comporteraient comme prévu ? Ou les deux seraient-ils des vecteurs pour toutes les sessions ?

Je ne conteste pas que les gens devraient pouvoir opter pour quelque chose comme ça. :le sourire:

deux séances distinctes

Oh, oui, cela devrait absolument fonctionner aujourd'hui - et ne pas √™tre un vecteur (celui √©lev√© fonctionne enti√®rement du c√īt√© High-IL du monde et ne peut √™tre pilot√© par aucun autre processus Medium-IL)

ça devrait absolument marcher aujourd'hui

Dans le même esprit, 2 onglets ne peuvent-ils pas tourner dans des traitements différents et ainsi permettre une élévation mixte dans une même fenêtre ?

@DHowett-MSFT Alors pourquoi les deux sessions distinctes ne peuvent-elles pas être hébergées dans l'application globale ? Ce n'est vraiment pas difficile à faire.

Je pense que je comprends les implications de s√©curit√© d'avoir des applications de console √©lev√©es en premier lieu, mais ce que je ne peux pas comprendre, c'est pourquoi avoir deux types d'onglets (√©lev√©s et non √©lev√©s) dans Windows Terminal serait _plus risqu√©_ que ce que Windows a pris en charge pour les √Ęges, c'est-√†-dire l'ex√©cution c√īte √† c√īte de CMD / PowerShell √©lev√©s et non √©lev√©s. Quelqu'un peut-il nous √©clairer √† ce sujet?

@robomac
[1] C'est trivial lorsque vous _h√©bergez des fen√™tres traditionnelles_ avec des poign√©es de fen√™tre traditionnelles. Cela fonctionne tr√®s bien dans le cas conemu, ou dans le cas du shell √† onglets, o√Ļ vous pouvez prendre en charge une fen√™tre dans une session √©lev√©e et la re-parent sous une fen√™tre dans une session non √©lev√©e.

Lorsque vous faites cela, il y a quelques fonctionnalités de sécurité que j'aborderai dans [2]. À cause de cela, vous pouvez le parent mais vous ne pouvez pas vraiment le forcer à faire quoi que ce soit.

Il y a un probl√®me, cependant. Le terminal n'est pas con√ßu comme une collection de fen√™tres re-parentables. Par exemple, il n'ex√©cute pas un h√īte de console et ne d√©place pas sa fen√™tre dans un onglet. Il a √©t√© con√ßu pour prendre en charge une "connexion" - quelque chose qui peut lire et √©crire du texte. C'est une primitive de niveau inf√©rieur √† une fen√™tre. Nous avons r√©alis√© l'erreur de nos mani√®res et avons d√©cid√© que le mod√®le UNIX avait raison tout le temps, et les canaux, le texte et les flux sont _l√† o√Ļ ils se trouvent._

√Čtant donn√© que nous utilisons des √ģlots Xaml pour h√©berger une interface utilisateur moderne et y assembler une surface DirectX, nous sommes de toute fa√ßon bien au-del√† du monde des poign√©es de fen√™tre standard. Les √ģles Xaml sont enti√®rement compos√©es en un seul HWND, un peu comme Chrome et Firefox et la gamme de jeux DirectX/OpenGL/SDL. Nous n'avons pas de composants qui peuvent √™tre ex√©cut√©s dans un processus (√©lev√©) et h√©berg√©s dans un autre (non √©lev√©) qui ne sont pas les "connexions" susmentionn√©es.

Maintenant, la question de suivi √©vidente est _"pourquoi ne pouvez-vous pas avoir une connexion √©lev√©e dans un onglet √† c√īt√© d'une connexion non √©lev√©e?"_ C'est l√† que @sba923 devrait reprendre la lecture (:smile:). Je vais probablement couvrir certaines choses que vous (@robomac) connaissez d√©j√†.

[2] Lorsque vous avez deux fenêtres sur le même bureau dans la même station Windows, elles peuvent communiquer entre elles. Je peux facilement utiliser SendKeys via WScript.Shell pour envoyer une entrée au clavier à n'importe quelle fenêtre que le shell peut voir.

L'exécution d'un processus a élevé _severs_ cette connexion. La coque ne peut pas voir la fenêtre surélevée. Aucun autre programme au même niveau d'intégrité que le shell ne peut voir la fenêtre élevée. Même s'il a sa poignée de fenêtre, il ne peut pas vraiment interagir avec lui. C'est aussi pourquoi vous ne pouvez pas glisser/déposer de l'explorateur dans le bloc-notes si le bloc-notes est exécuté en mode élevé. Seul un autre processus élevé peut interagir avec une autre fenêtre élevée.

Cette fonctionnalité de "sécurité" (appelez-la comme vous voulez, elle était probablement destinée à être une fonctionnalité de sécurité à un moment donné) n'existe que pour quelques types d'objets globaux de session. Les fenêtres en font partie. Les tuyaux n'en font pas vraiment partie.

Pour cette raison, il est trivial de briser cette s√©curit√©. Prenons le terminal comme exemple. Si nous commen√ßons une connexion √©lev√©e et l'h√©bergeons dans une fen√™tre _non √©lev√©e_, nous avons soudainement cr√©√© un conduit √† travers cette limite de s√©curit√©. La chose sur√©lev√©e √† l'autre bout n'est pas une fen√™tre, c'est juste une application en mode texte. Il fait imm√©diatement les ench√®res de l'h√īte non √©lev√©.

Quiconque peut _contr√īler_ l'h√īte non √©lev√© (comme WScript.Shell::SendKeys ) _√©galement_ obtient un conduit instantan√© √† travers la limite d'√©l√©vation. Soudainement, n'importe quelle application d'int√©grit√© moyenne sur votre syst√®me peut contr√īler un processus d'int√©grit√© √©lev√©e. Cela pourrait √™tre votre navigateur, ou le mineur de bitcoin qui a √©t√© install√© avec le package left-pad de NPM, ou vraiment n'importe quel nombre de choses.

C'est un petit risque, mais c'est un risque.


D'autres plates-formes ont accepté ce risque de préférence pour la commodité de l'utilisateur. Ils n'ont pas tort de le faire, mais je pense que Microsoft obtient moins de "passe" sur des choses comme "accepter le risque pour la commodité de l'utilisateur". Windows 9x était un désastre de sécurité absolu, et les comptes d'utilisateurs limités et les invites d'élévation et la sécurité au niveau du noyau pour la gestion des fenêtres étaient la réponse à ces problèmes. Ce ne sont pas des serrures à desserrer légèrement.

@ DHowett-MSFT Merci beaucoup pour la clarification. Je pense que nous devrons nous habituer √† ex√©cuter une instance √©lev√©e de Windows Terminal et une instance non √©lev√©e c√īte √† c√īte, un peu comme nous le faisons avec les applications de console ces jours-ci.

Fascinant. Merci. Terminal √©tant plus un moteur de rendu de connexion qu'une fen√™tre, cela a du sens. Cela donne-t-il √† PowerShell, d√©j√† plut√īt ax√© sur les canaux/connexions, un contr√īle suppl√©mentaire sur une console fen√™tr√©e¬†?

Les sessions Terminal distinctes sont-elles entièrement isolées les unes des autres ?

Je serais entièrement satisfait d'avoir simplement une indication que je suis dans une session élevée. Comme "Administrateur : \ Ça me manque pas mal en ce moment.

image

???

"Exécuter en tant qu'utilisateur différent" est une chose dont tous les administrateurs Windows ont besoin ! Ce serait très utile s'il est disponible. La meilleure option serait de l'avoir avec un indicateur dans la configuration de chaque profil.

BTW, en parlant d'isolation de fenêtre, permettez-moi de citer le dernier rapport de vulnérabilité ctfmon

L'attaque évidente est un utilisateur non privilégié injectant des commandes dans la session de la console d'un administrateur ou lisant les mots de passe lorsque les utilisateurs se connectent. Même les processus AppContainer en bac à sable peuvent effectuer la même attaque.

@ecki C'est une nouvelle assez troublante. Je suis s√Ľr que Tavis est parti faire la f√™te ce soir apr√®s celui-l√†.

@DHDHowett-MSFT
Comme beaucoup ici l'ont √©crit, si le nouveau terminal n'est pas capable de d√©marrer avec l'option "ex√©cuter en tant qu'utilisateur diff√©rent" que pour un grand nombre d'utilisateurs, il n'est pas tr√®s utilisable, il n'est pas non plus compatible avec le "mod√®le de niveau administratif Active Directory" de Microsoft si vous avez par exemple un utilisateur AD avec des droits par d√©faut, et ex√©cutez des scripts PS avec un administrateur sur un contr√īleur de domaine.

Je n'ai pas beaucoup de cas o√Ļ je d√©marre un terminal avec mon utilisateur actuellement connect√©‚Ķ alors je vous demande, quel est le cas d'utilisation de ce terminal ? Ping, nslookup, etc., si telle est l'intention, pourquoi mettez-vous autant de travail dans tout cela¬†?

Avec "ex√©cuter en tant qu'administrateur", vous avez des points valables, mais pourquoi d'autres consoles comme (PS6/7) prennent toujours en charge ces fonctions, si ce n'est pas s√Ľr¬†?

J'ai toujours pensé que la nouvelle application Terminal remplacerait toutes les fenêtres cmd/PS/… séparées, mais il semble qu'elle ne soit pas utilisable dans de nombreux scénarios du monde réel. C'est un peu triste tbh...

@Fisico votre expérience n'est pas universelle, et je vous encourage à en tenir compte lorsque vous demandez à quelqu'un de justifier l'existence même de son projet.

Pour votre point général sur "exécuter en tant qu'utilisateur différent" qui n'existe pas/ne fonctionne pas : il s'agit d'une limitation de la plate-forme que nous essayons de lever. Ce n'est pas par malveillance ou par incompétence que nous ne l'appuyons pas.

Quant à la raison pour laquelle d'autres applications de console le prennent en charge, ce n'est pas dangereux lorsqu'ils le font, car ils n'hébergent spécifiquement pas différents niveaux d'élévation dans la même fenêtre. C'est le problème central ici. Parce qu'ils sont hébergés dans des processus autonomes avec des fenêtres autonomes, ils sont exempts de la restriction sur la manipulation au niveau de l'intégrité croisée.

@DHowett-MSFT
Désolé si je vous ai offensé avec mon message, ce n'était pas mon intention, j'y ai mis trop d'émotion.
Je pense que le Terminal est une excellente idée et a un très gros potentiel et je suis heureux que vous le développiez avec la communauté pour en tirer le meilleur parti.

√Ä ce stade, il y a tellement de confusion sur ce qui est mis en Ňďuvre et ce qui ne l'est pas.
"Exécuter en tant qu'administrateur" pour l'ensemble de l'application fonctionne pour le moment, est-ce là pour rester ?

Si je comprends bien, "Exécuter en tant qu'administrateur" pour chaque onglet/profil n'est pas quelque chose que vous souhaitez implémenter. Je pense que cela convient à la plupart d'entre nous.

"Exécuter en tant qu'utilisateur différent" n'est pas possible car Windows ne le prend pas en charge pour les applications, et vous/nous devons attendre que Windows le prenne en charge ? Si oui parle-t-on d'années ?

"Exécuter en tant qu'utilisateur différent" par onglet/profil est également quelque chose que vous ne souhaitez pas implémenter ?

@DHDHowett-MSFT
Comme beaucoup ici l'ont écrit, si le nouveau terminal n'est pas en mesure de démarrer avec l'option "exécuter en tant qu'utilisateur différent"
que pour un grand nombre d'utilisateurs, ce n'est pas très utilisable, ... J'ai toujours pensé que la nouvelle application Terminal
remplacez toutes les fenêtres cmd/PS/… séparées, mais il semble qu'elles ne soient pas utilisables dans de nombreux scénarios réels. C'est un peu triste tbh...

Je ne suis pas d'accord. C'est une √©norme avanc√©e par rapport √† ce que nous avions auparavant. Malheureusement, la plupart d'entre nous ont probablement pris l'habitude de faire fonctionner nos coquilles en hauteur faute d'une approche plus granulaire... et nous le pouvons toujours. Nous ne pouvons pas les m√©langer... mais nous ne l'avons jamais fait. S√©rieusement, dans les _trois derni√®res_ entreprises o√Ļ j'ai √©t√©, le Developer Wiki a effectu√© toutes les versions/tests dans une invite VS √©lev√©e. Nous impl√©mentons la s√©curit√© via des analyses en temps r√©el, des pare-feu actifs agressifs et sachant que nos d√©veloppeurs se trompent rarement. Les _non-d√©veloppeurs_ ne s'ex√©cutent jamais avec des privil√®ges √©lev√©s, car (1) nous ne pouvons pas leur faire confiance et (2) ils n'en ont pas besoin.

Donc, pour ma part, j'apprécie ce nouveau terminal. Ce n'est pas parfait, mais Take Command / TCC non plus. Au moins c'est standard.

@DHDHowett-MSFT
Comme beaucoup ici l'ont écrit, si le nouveau terminal n'est pas en mesure de démarrer avec l'option "exécuter en tant qu'utilisateur différent"
que pour un grand nombre d'utilisateurs, ce n'est pas très utilisable, ... J'ai toujours pensé que la nouvelle application Terminal
remplacez toutes les fenêtres cmd/PS/… séparées, mais il semble qu'elles ne soient pas utilisables dans de nombreux scénarios réels. C'est un peu triste tbh...

Je ne suis pas d'accord. C'est une √©norme avanc√©e par rapport √† ce que nous avions auparavant. Malheureusement, la plupart d'entre nous ont probablement pris l'habitude de faire fonctionner nos coquilles en hauteur faute d'une approche plus granulaire... et nous le pouvons toujours. Nous ne pouvons pas les m√©langer... mais nous ne l'avons jamais fait. S√©rieusement, dans les _trois derni√®res_ entreprises o√Ļ j'ai √©t√©, le Developer Wiki a effectu√© toutes les versions/tests dans une invite VS √©lev√©e. Nous impl√©mentons la s√©curit√© via des analyses en temps r√©el, des pare-feu actifs agressifs et sachant que nos d√©veloppeurs se trompent rarement. Les _non-d√©veloppeurs_ ne s'ex√©cutent jamais avec des privil√®ges √©lev√©s, car (1) nous ne pouvons pas leur faire confiance et (2) ils n'en ont pas besoin.

Donc, pour ma part, j'apprécie ce nouveau terminal. Ce n'est pas parfait, mais Take Command / TCC non plus. Au moins c'est standard.

élevé != exécuter en tant qu'utilisateur différent.
J'exécute davantage PowerShell avec d'autres utilisateurs AD, puis avec le mien.
Je suis avec vous que vous ex√©cutez souvent un cmd ou un PS en tant qu'administrateur m√™me si vous n'y √™tes pas oblig√©, mais il y a tellement de cas o√Ļ vous devez l'ex√©cuter en tant qu'administrateur. La plupart des t√Ęches d'administration syst√®me n√©cessitent des droits d'administrateur ou un utilisateur diff√©rent avec une sorte de privil√®ges.
Bien s√Ľr, si vous devez ex√©cuter des cmd dans un contexte utilisateur, tout va bien.

Je comprends que "élevé ! = exécuter en tant qu'utilisateur différent". Je ne crois tout simplement pas que "exécuter en tant qu'utilisateur différent" soit aussi courant que vous le prétendez.

Je comprends que "élevé ! = exécuter en tant qu'utilisateur différent". Je ne crois tout simplement pas que "exécuter en tant qu'utilisateur différent" soit aussi courant que vous le prétendez.

Si vous avez quelque chose à voir avec l'univers Microsoft, vous en avez absolument besoin.
Ce n'est pas la meilleure idée de se connecter à des machines Windows avec des droits d'administrateur de domaine par exemple.
L'exécution de scripts PS avec un utilisateur disposant de droits d'administrateur de domaine ou d'autres droits est très courante.

@Fisico pourquoi ne pas utiliser la commande New-PSSession alors ?

Les scripts automatis√©s qui n√©cessitent un certain type d'√©l√©vation sp√©cifique pour un service n√©cessitent g√©n√©ralement une "ex√©cution en tant qu'utilisateur diff√©rent". Que cela s'applique √† Terminal est une autre histoire. Vous pouvez toujours modifier votre connexion une fois dans une session CMD ou PS √† l'aide de la commande runas . Cela ne changerait pas l'√©tat d'√©l√©vation de l'onglet car il utilise la connexion sous-jacente, qui est votre utilisateur habituel. De plus, tous les scripts que vous ex√©cuteriez √† l'aide du Planificateur de t√Ęches ou d'une t√Ęche cron ne n√©cessiteront pas l'ex√©cution de Terminal, sauf si vous l'utilisez pour obtenir une fonctionnalit√© qui n'existe pas dans une session de console normale. Si tel est le cas, l'utilisation de param√®tres pour ex√©cuter ce script avec Terminal, qui se lance en arri√®re-plan, serait la solution.

Par conséquent, une élévation mixte pour les onglets n'est pas nécessaire. Nous avons une solution de contournement et il est assez facile de copier les commandes runas spécifiques dont vous avez besoin dans un fichier txt que vous pouvez copier/coller dans le terminal, puis remplir votre mot de passe (vous ne devez jamais enregistrer votre mot de passe sur tout ce qui n'est pas crypté).

@SamuelEnglard
Je ne veux pas me connecter √† un h√īte distant pour ex√©cuter un script.

@WSLUser oui, c'est une option pour utiliser des runas, mais il est beaucoup plus pratique d'exécuter simplement le terminal ou le PS en tant qu'utilisateur différent. Je ne vois pas pourquoi cela devrait être un problème.

@Fisico New-PSSession n'a pas besoin de se connecter à un ordinateur distant, voir la deuxième première entrée de syntaxe.

@SamuelEnglard
Je ne veux pas me connecter √† un h√īte distant pour ex√©cuter un script.

@WSLUser oui, c'est une option pour utiliser des runas, mais il est beaucoup plus pratique d'exécuter simplement le terminal ou le PS en tant qu'utilisateur différent. Je ne vois pas pourquoi cela devrait être un problème.

C'est une op√©ration assez standard pour un utilisateur d'√©pingler PowerShell √† la barre des t√Ęches et de cliquer avec le bouton droit pour s'ex√©cuter en tant qu'administrateur ou dans certains environnements RunAs OtherUser car un compte √©lev√© est n√©cessaire pour ex√©cuter un script de niveau entreprise. Dire que ce n'est pas possible pour le terminal, c'est comme les environnements qui exploitent PSLockDown et forcent RunAs Admin juste √† charger le shell ou VSCode
A mon humble avis

Si vous avez vraiment besoin qu'un onglet s'exécute en tant qu'utilisateur différent, vous pouvez avoir un profil qui s'exécute New-PSSession -Credential | Enter-PSSession au démarrage.

AVIS DE NON- RESPONSABILIT√Ȭ†: Je ne prends aucune responsabilit√© pour les ordinateurs d√©truits √† cause de cela.

Si vous avez vraiment besoin qu'un onglet s'exécute en tant qu'utilisateur différent, vous pouvez avoir un profil qui s'exécute New-PSSession -Credential | Enter-PSSession au démarrage.

> AVIS DE NON- RESPONSABILIT√Ȭ†: Je n'assume aucune responsabilit√© pour les ordinateurs d√©truits √† cause de cela.

Bien s√Ľr, ou la "s√©curit√©" qui se tient ici pourrait √™tre reconsid√©r√©e. Encore une fois, j'√©pingle PowerShell √† ma barre des t√Ęches, √† partir de l√†, je peux lancer PowerShell sans √©l√©vation ; Je peux cliquer dessus avec le bouton droit de la souris et choisir "Ex√©cuter en tant qu'administrateur" et si dans un environnement d'entreprise, je peux cliquer avec le bouton droit sur l'ic√īne, puis Maj-Clic droit sur "Windows PowerShell" et s√©lectionner "Ex√©cuter en tant qu'utilisateur diff√©rent" pour lancer PowerShell avec des identifiants alternatifs. Pas de sessions, pas de RDP vers un autre h√īte pour obtenir ces cr√©dits.

Bien s√Ľr, ou la "s√©curit√©" qui se tient ici pourrait √™tre reconsid√©r√©e. Encore une fois, j'√©pingle PowerShell √† ma barre des t√Ęches, √† partir de l√†, je peux lancer PowerShell sans √©l√©vation ; Je peux cliquer dessus avec le bouton droit de la souris et choisir "Ex√©cuter en tant qu'administrateur" et si dans un environnement d'entreprise, je peux cliquer avec le bouton droit sur l'ic√īne, puis Maj-Clic droit sur "Windows PowerShell" et s√©lectionner "Ex√©cuter en tant qu'utilisateur diff√©rent" pour lancer PowerShell avec des identifiants alternatifs. Pas de sessions, pas de RDP vers un autre h√īte pour obtenir ces cr√©dits.

Oui, et je peux aussi le faire avec Windows Terminal. D'accord. Je ne vois pas comment cela aide ceux qui veulent avoir un mélange d'onglets qui s'exécutent en tant qu'utilisateurs différents (ou élévation différente).

"onglets mixtes" mis à part, je veux juste clarifier, vous NE POUVEZ PAS faire cela avec (l'aperçu publié) Windows Terminal en raison de la conception des applications Windows Store. Vous ne pouvez exécuter que l'utilisateur qui a installé cette application et qui s'est connecté avec ce même utilisateur.

Tout ce que je veux, c'est pouvoir faire ce que je fais aujourd'hui, me connecter au PC en tant qu'utilisateur normal et exécuter des shells élevés. Si Windows Terminal est publié tel quel, il ne me sert à rien.

Très bon point. Cette limitation n'existe pas avec les versions privées (hors magasin) de Windows Terminal.

"onglets mixtes" mis à part, je veux juste clarifier, vous NE POUVEZ PAS faire cela avec (l'aperçu publié) Windows Terminal en raison de la conception des applications Windows Store. Vous ne pouvez exécuter que l'utilisateur qui a installé cette application et qui s'est connecté avec ce même utilisateur.

Tout ce que je veux, c'est pouvoir faire ce que je fais aujourd'hui, me connecter au PC en tant qu'utilisateur normal et exécuter des shells élevés. Si Windows Terminal est publié tel quel, il ne me sert à rien.

Je viens d'ouvrir 2 instances de la version de magasin de Windows Terminal - une élevée et une non. Donc je ne sais pas pourquoi ça ne marche pas pour toi.

Ok, je dois croire que vous êtes un administrateur local sur votre PC. Pour être clair, je devrais peut-être préciser. Je ne suis jamais administrateur local sur mon poste de travail. Ainsi, lorsque je vais sur "Exécuter en tant qu'administrateur", je suis invité à saisir un utilisateur/mot de passe.

Le compte 'admin' que j'utilise est différent de mon compte habituel de lecture de malware/email. Donc, techniquement, ce que je fais, c'est exécuter en tant qu'utilisateur différent. Il s'agit de la limitation de l'application Windows Store. La solution (et peut-être qu'ils le feront) est de le publier en tant que composant Windows qui n'aura pas ces limitations.

image

* [URGENT] TOUS J'AI TROUV√Č UNE SOLUTION √Ä CE PROBL√ąME¬†! * *

En suivant ce guide
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
vous pouvez personnaliser le dossier de l'application Windows !

une fois que vous avez fait cela, vous pouvez localiser le dossier Microsoft.WindowsTerminal._blahblahYourVersion_ . Une fois à l'intérieur, localisez WindowsTerminal.exe illustré ci-dessous
image

Une fois que vous l'avez trouv√©, cr√©ez un raccourci de ce fichier et placez-le o√Ļ vous le souhaitez. Apr√®s cela, configurez-le pour qu'il s'ex√©cute en tant qu'administrateur. Vous pouvez le faire en cliquant avec le bouton droit de la souris et en allant dans _Propri√©t√©s> Avanc√©> Ex√©cuter en tant qu'administrateur_ Apr√®s cela, cliquez sur OK et vous √™tes pr√™t¬†!

Personnellement, j'en avais besoin car j'utilise le raccourci dans ma barre des t√Ęches pour pouvoir simplement appuyer sur _Windows + 1_ pour le lancer en tant qu'administrateur. Pas le long chemin de navigation dans mon menu de d√©marrage pour l'ex√©cuter correctement.

Vous pouvez également simplement décompresser le bundle que nous avons mis sur la page des versions. C'est juste un fichier ZIP. Veuillez noter que nous _ne prenons pas officiellement en charge_ l'exécution sans package !

Mais cela signifie toujours qu'il n'y a aucun moyen _supporté_ d'exécuter une élévation ! Je pense que c'est une fonctionnalité indispensable.

image
image

En effet, je suis corrigé.

Ce qui manque, c'est l'entr√©e "Ex√©cuter en tant qu'administrateur" dans le menu contextuel du raccourci de la barre des t√Ęches.

Hier, j'ai parlé à quelques personnes lors d'une rencontre et quelques personnes ont déclaré qu'elles lançaient principalement Powershell avec Windows + X et qu'elles aimeraient avoir un terminal / terminal en tant qu'administrateur.

Très bon point !

C'est exactement mon propos ! C'est la solution pour l'ex√©cuter √† partir de la barre des t√Ęches
avec des privilèges d'administrateur !

Le dim. 25 ao√Ľt 2019, 01:08 St√©phane BARIZIEN [email protected]
a écrit:

Très bon point !

‚ÄĒ
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q#issuecomment-52460
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

En effet, je suis corrigé.

Ce qui manque, c'est l'entr√©e "Ex√©cuter en tant qu'administrateur" dans le menu contextuel du raccourci de la barre des t√Ęches.

Dans la barre des t√Ęches, cliquez deux fois avec le bouton droit de la souris. Une fois sur l'ic√īne pour faire appara√ģtre le menu contextuel, puis une seconde fois sur le nom de l'application. par exemple "Terminal Windows (Aper√ßu)" et choisissez "Ex√©cuter en tant qu'administrateur"

image

Je suis confus.

Rougir.

Honteux.

Comment se fait-il que je n'y ai pas pensé ?

Merci quand même de partager avec nous tous !

Regardons le probl√®me de l'autre c√īt√©...
Windows permet aux processus non √©lev√©s de contr√īler d'autres processus non √©lev√©s, d'envoyer des frappes au clavier, de capturer leur interface utilisateur, etc., mais emp√™che les processus non √©lev√©s de le faire dans une fen√™tre d'un processus √©lev√©.
Le terminal Windows est conçu pour être également utilisé pour gérer des serveurs distants, via ssh, PowerShell remoting, etc...
Cela signifie que le terminal Windows devient une faille de sécurité dès qu'il est utilisé pour l'administration, car un logiciel malveillant local pourrait attendre une session du terminal Windows pour espionner ce que fait l'utilisateur, et dès qu'il détecte un shell distant, essayez de injecter des commandes pour infecter le serveur en utilisant les droits d'administrateur.

Emp√™cher le terminal Windows d'√™tre ex√©cut√© en tant qu'administrateur ne semble pas du tout √™tre une am√©lioration de la s√©curit√©, car l'ex√©cuter en tant qu'administrateur prot√©gerait plut√īt l'utilisateur contre les processus non √©lev√©s d√©tournant leurs sessions shell distantes. L'ex√©cuter en tant qu'administrateur devrait √™tre recommand√© √† l'utilisateur chaque fois qu'il utilise un outil qui lui donne une invite de commande √©lev√©e, localement ou √† distance.

Et à propos de sudo pour Windows, l'exécution du service sshd, puis la connexion à localhost à partir d'un shell non élevé ne présentent-elles pas le même problème de sécurité ?

Cela signifie que le terminal Windows devient une faille de sécurité dès qu'il est utilisé pour l'administration, car un logiciel malveillant local pourrait attendre une session du terminal Windows pour espionner ce que fait l'utilisateur, et dès qu'il détecte un shell distant, essayez de injecter des commandes pour infecter le serveur en utilisant les droits d'administrateur.

S'il est vrai que le système distant peut être infecté (en supposant que le processus distant dispose de droits d'administrateur), cela ne signifie pas que nous devrions également le laisser infecter le système local.

Emp√™cher le terminal Windows d'√™tre ex√©cut√© en tant qu'administrateur ne semble pas du tout √™tre une am√©lioration de la s√©curit√©, car l'ex√©cuter en tant qu'administrateur prot√©gerait plut√īt l'utilisateur contre les processus non √©lev√©s d√©tournant leurs sessions shell distantes. L'ex√©cuter en tant qu'administrateur devrait √™tre recommand√© √† l'utilisateur chaque fois qu'il utilise un outil qui lui donne une invite de commande √©lev√©e, localement ou √† distance.

Rien ne vous empêche d'exécuter le terminal Windows avec des droits d'administrateur pour le moment. Le problème qui se pose est d'avoir des onglets mixtes élevés et non élevés.

@SamuelEnglard sur place sur la réponse.

Pour ajouter, ce que nous essayons de faire est d'éviter d'ajouter de _nouveaux_ trous de sécurité. La console d'origine avait les mêmes problèmes avec la gestion du serveur distant. Nous ne pouvons rien y faire malheureusement. Les utilisateurs qui gèrent des serveurs à distance exécutent toujours leurs consoles/terminaux élevés, ce qui leur donnera une sécurité supplémentaire (bien que je ne sois pas un expert en sécurité et que je n'interpréterais pas cette déclaration comme un conseil)

Id√©e pour progresser sur ce probl√®me¬†: essayez d'ex√©cuter l'ensemble de l'_app_ en mode √©lev√©, et si cela r√©ussit, ajoutez un bouton √† c√īt√© de chaque bouton "ouvrir" avec l'ic√īne d'un bouclier UAC, et ajoutez un raccourci clavier de pr√©fixe pour ouvrir un onglet √©lev√©¬†: Ctrl Maj E . (J'ai v√©rifi√© et ce n'√©tait pas li√©.) Cela ne fonctionne que pour le prochain onglet ouvert.

Quoi qu'il en soit, les onglets ouverts ont une ic√īne UAC avant leur ic√īne habituelle et sont ex√©cut√©s en tant qu'administrateur. (N'oubliez pas que les programmes ne peuvent plus envoyer ces cl√©s. Nous avons ex√©cut√© l'application en tant qu'administrateur.)

L'application devrait essayer de s'élever automatiquement, et si cela échoue, s'exécuter normalement et ignorer tout ce fil.

En effet, je suis corrigé.
Ce qui manque, c'est l'entr√©e "Ex√©cuter en tant qu'administrateur" dans le menu contextuel du raccourci de la barre des t√Ęches.

Dans la barre des t√Ęches, cliquez deux fois avec le bouton droit de la souris. Une fois sur l'ic√īne pour faire appara√ģtre le menu contextuel, puis une seconde fois sur le nom de l'application. par exemple "Terminal Windows (Aper√ßu)" et choisissez "Ex√©cuter en tant qu'administrateur"

image

Je viens de remarquer que l'invite UAC que l'on obtient dans ce cas indique "Programme inconnu".

Plut√īt inattendu si vous me demandez...

@sba923 c'est #2289 :sourire:

@ DHowett-MSFT merci pour l'info ; bon à savoir que c'est (déjà) suivi.

La meilleure réponse à laquelle je puisse penser est d'avoir la possibilité d'avoir un profil qui doit être élevé et si la fenêtre actuelle n'est pas élevée, démarrez une nouvelle instance élevée avec ce profil. (Pensez au fonctionnement des sessions de navigation privées)

Très bonne idée

J'ai utilisé cette méthode pour ajouter le Terminal dans le menu Win+X :
Créez un nouveau raccourci avec la cible :
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!App
√Čditer:
Désolé, cela ne fonctionnera pas si vous souhaitez exécuter l'application en tant qu'administrateur.
Au lieu de cela, vous pouvez utiliser nircmd et créer un raccourci avec
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(le chemin correct pour "Microsoft.WindowsTerminal_xxxxxxxxxxxx" peut être trouvé avec la commande PS "Get-appxpackage *WindowsTerminal*", utilisez l'entrée dans PackageFamilyName)

Ce raccourci peut être utilisé pour démarrer le terminal avec des privilèges d'administrateur avec un simple double-clic et avec WinXEditor, il peut être ajouté dans le menu Win+X.
Remarque : Le terminal doit également être installé dans le compte administrateur.

2019-10-08 10_37_19-

L'idée est-elle de charger chaque profil en tant qu'administrateur ou seulement certains ? Idéalement, j'aimerais l'avoir par profil individuel. Peut-être une propriété qui est le compte "runas" et une autre comme "iselevated" ?

Comme discuté en détail dans ce fil, vous ne pouvez pas avoir un mélange d'élévation et de non élévation dans la même instance de Windows Terminal, et cela ne sera pas ajouté.

En effet, je suis corrigé.
Ce qui manque, c'est l'entr√©e "Ex√©cuter en tant qu'administrateur" dans le menu contextuel du raccourci de la barre des t√Ęches.

Dans la barre des t√Ęches, cliquez deux fois avec le bouton droit de la souris. Une fois sur l'ic√īne pour faire appara√ģtre le menu contextuel, puis une seconde fois sur le nom de l'application. par exemple "Terminal Windows (Aper√ßu)" et choisissez "Ex√©cuter en tant qu'administrateur"
image

FWIW, je viens de tester shift-and-right-click qui donne immédiatement l'option "Exécuter en tant qu'administrateur" - seulement légèrement plus rapide que l'option à deux clics droits qui était auparavant ma préférée.

image

Hé les gars, avez-vous oublié l'UAC ? L'application ne peut pas cliquer sur les éléments du bureau sécurisé.

FWIW, je viens de tester shift-and-right-click qui donne immédiatement l'option "Exécuter en tant qu'administrateur" - seulement légèrement plus rapide que l'option à deux clics droits qui était auparavant ma préférée.

image

Vous pouvez √©galement ctrl + shift + clic gauche sur l'ic√īne pour faire appara√ģtre l'UAC instantan√©ment.

Génial, merci beaucoup ! Combien de raccourcis devons-nous retenir ? ;-)

Pour votre point général sur "exécuter en tant qu'utilisateur différent" qui n'existe pas/ne fonctionne pas : il s'agit d'une limitation de la plate-forme que nous essayons de lever. Ce n'est pas par malveillance ou par incompétence que nous ne l'appuyons pas.

Quant à la raison pour laquelle d'autres applications de console le prennent en charge, ce n'est pas dangereux lorsqu'ils le font, car ils n'hébergent spécifiquement pas différents niveaux d'élévation dans la même fenêtre. C'est le problème central ici. Parce qu'ils sont hébergés dans des processus autonomes avec des fenêtres autonomes, ils sont exempts de la restriction sur la manipulation au niveau de l'intégrité croisée.

J'espère vraiment que courir en tant qu'utilisateur différent est quelque chose qui arrive à un moment donné. Bien que ce ne soit pas la majorité de mon activité quotidienne, certaines applets de commande powershell nécessitent une élévation (et je cours avec différents utilisateurs, pensez à un administrateur utilisateur protégé).

Ce n'est pas la fin du monde, mais ce sera certainement ennuyeux de devoir revenir aux obus hérités.

Avec le temps, je suppose !

Il n'y a absolument aucun probl√®me/limitation avec l'utilisation de Windows Terminal √©lev√©, donc pas besoin de s'en tenir aux "shells h√©rit√©s" (ou pour √™tre plus exact : √† l'h√īte de la console h√©rit√©e).

C'est juste que vous ne pouvez pas mélanger les niveaux élevés et non élevés dans (différents onglets dans) la même instance .

Il n'y a absolument aucun probl√®me/limitation avec l'utilisation de Windows Terminal √©lev√©, donc pas besoin de s'en tenir aux "shells h√©rit√©s" (ou pour √™tre plus exact : √† l'h√īte de la console h√©rit√©e).

C'est juste que vous ne pouvez pas mélanger les niveaux élevés et non élevés dans (différents onglets dans) la même instance .

Je suppose que j'ai peut-être mal interprété ce qui précède, mais il y a une limitation de la plate-forme avec l'exécution du terminal dans un contexte utilisateur complètement différent de ce que je lis.

Je suppose que j'ai peut-être mal interprété ce qui précède, mais il y a une limitation de la plate-forme avec l'exécution du terminal dans un contexte utilisateur complètement différent de ce que je lis.

Yah, ce fil a été partout sur le plateau sur ce point. Je ne suis pas administrateur sur mes postes de travail, donc "exécuter en tant qu'administrateur" m'invite simplement à saisir mes "informations d'identification élevées".

Nous devrions probablement simplement avoir un nouveau fil de discussion sur ce cas d'utilisation.

Pour √™tre clair, ce que je veux dire (et je pense que beaucoup d'"administrateurs" en ont besoin) est la possibilit√© d'√™tre connect√© √† notre poste de travail en tant qu'utilisateur normal. Ensuite, ex√©cutez ¬ę¬†un shell¬†¬Ľ en tant qu'utilisateur √©lev√©, comme dans l'administrateur de domaine, par exemple, pour effectuer le travail AD.

Vrai ou faux, c'est ce que certains d'entre nous font et ont besoin. Toutes les astuces concernant l'installation de la console à partir du magasin en tant qu'utilisateur et la conception de raccourcis intelligents n'ont pas vraiment fonctionné pour moi.

Et oui, je peux le faire de plusieurs façons et peut-être devrais-je limiter certaines de ces activités à un poste de travail protégé, mais la réalité est qu'en tant qu'utilisateur normal, je n'ai généralement pas besoin d'un shell.

IMVHO la confusion vient du fait que les gens utilisent plus ou moins indifféremment les termes "élevé" et "en tant qu'autre utilisateur [domaine] [admin]".

Exécuter en tant qu'autre utilisateur n'est pas la même chose qu'exécuter avec une élévation de privilèges.

  1. Certaines personnes sur ce fil ont besoin, lorsqu'elles sont connectées en tant qu'utilisateur administrateur, d'exécuter des charges de travail Windows Terminal avec élévation.

  2. Certaines autres personnes ont besoin, lorsqu'elles sont connectées en tant qu'utilisateur normal (ou non administrateur de domaine), d'exécuter des charges de travail Windows Terminal en tant qu'autre utilisateur administrateur, généralement avec élévation.

  3. On pourrait √©galement envisager le cas o√Ļ des personnes sont connect√©es en tant qu'utilisateur normal A et souhaitent ex√©cuter des charges de travail Windows Terminal en tant qu'utilisateur B sans √©l√©vation.

Dans #2 et #3, le d√©ploiement bas√© sur Windows Store rend l'histoire plus complexe, car Windows Terminal ne s'ex√©cutera pas en tant qu'utilisateur connect√©, o√Ļ les "applications de magasin" sont d√©ploy√©es pour cet utilisateur.

J'espère que j'ai bien compris la situation. Si je le fais, j'espère que cela clarifie un peu la question.

Vous avez bien compris.

Juste pour info, ce problème exact, incapable d'élever ("Exécuter en tant qu'administrateur", par opposition à l'exécution en tant qu'autre utilisateur administratif, "Exécuter en tant qu'utilisateur différent") lorsque le compte avec lequel vous êtes connecté n'est pas un administrateur local sur le système, selon les meilleures pratiques), a été brièvement abordé dans un autre numéro : https://github.com/microsoft/terminal/issues/1538 . Cela a été fermé avec une explication selon laquelle il s'agissait d'un problème Windows, pas d'un problème Terminal, car cela semble être une limitation des applications Store.

Sans entrer dans un d√©bat quant √† savoir si cela aurait d√Ľ √™tre publi√© en tant qu'installation MSI au lieu d'utiliser le magasin, il existe une solution de contournement dans ce fil que j'ai utilis√©; connectez-vous bri√®vement en tant que votre compte administrateur, installez l'application depuis le Store, puis d√©connectez-vous √† nouveau. Ex√©cuter en tant qu'administrateur a ensuite fonctionn√© pour mon compte d'utilisateur normal (jusqu'√† la prochaine mise √† jour, quand il faudra le refaire).

Oui, il devrait y avoir un MSI disponible. Mon nouvel employeur n'autorise pas les installations de magasin (public) donc la seule façon pour moi d'utiliser Windows Terminal sera de construire à partir de la source...

D√©√ßu de voir que vous ne pouvez pas ex√©cuter Windows Terminal "en tant qu'administrateur" sans erreur et que vous devez ensuite impl√©menter une solution de contournement. Je dirais que beaucoup d'entreprises mettent en Ňďuvre une approche de s√©paration des privil√®ges pour les identit√©s (les employ√©s des TIC ayant un compte privil√©gi√© et non privil√©gi√©). Ainsi, √™tre en mesure de r√©pondre √† cette exigence en fournissant un d√©ploiement MSI facultatif conform√©ment √† la suggestion de @ sba923 serait une approche int√©ressante jusqu'√† ce que les applications group√©es du magasin puissent faire face √† la s√©paration des privil√®ges¬†?

Il s'agit d'un PREVIEW même pas de la version 1.0...

Je pense que ce sujet a été assez bien discuté à ce stade, mais il y a une perspective que je n'ai pas encore comprise : pourquoi ne pouvons-nous pas créer un raccourci Windows vers cette application ? C'est la solution de contournement typique pour "toujours lancer en tant qu'administrateur" - la solution de contournement typique consiste à créer un raccourci et à modifier le raccourci pour utiliser l'accès élevé par défaut.

Quelqu'un peut-il m'expliquer pourquoi nous ne pouvons pas créer de raccourci vers cette application ? Ceci est probablement plus lié au fonctionnement interne de Windows qu'au fonctionnement interne de Terminal, mais j'ai l'impression que nous tournons autour du pot si je ne le demande pas directement.

Merci.

Je garde nircmd dans mon dossier c:\utils avec de nombreux autres outils couramment utilisés.
J'ai ajouté un profil qui ressemble à ceci:

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

Il affiche une demande d'élévation UAC, puis ouvre une instance d'administration de Windows Terminal. C'est une solution de contournement décente pour le moment.

Honnêtement, je serais d'accord avec la possibilité de marquer les sessions comme élevées et de les ouvrir dans une nouvelle fenêtre.

Je suis venu ici à la recherche d'une solution intéressante, mais comme elle ne semble pas exister, je vais simplement partager ma solution hacky-ish. J'ai ajouté un profil pour exécuter PowerShell avec élévation :

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

Il appara√ģt dans une fen√™tre s√©par√©e, mais il fait le travail.

Je pense que ce sujet a été assez bien discuté à ce stade, mais il y a une perspective que je n'ai pas encore comprise : pourquoi ne pouvons-nous pas créer un raccourci Windows vers cette application ? C'est la solution de contournement typique pour "toujours lancer en tant qu'administrateur" - la solution de contournement typique consiste à créer un raccourci et à modifier le raccourci pour utiliser l'accès élevé par défaut.

Quelqu'un peut-il m'expliquer pourquoi nous ne pouvons pas créer de raccourci vers cette application ? Ceci est probablement plus lié au fonctionnement interne de Windows qu'au fonctionnement interne de Terminal, mais j'ai l'impression que nous tournons autour du pot si je ne le demande pas directement.

Merci.

@aaronsteers , vous avez raison, il s'agit plus de Windows que de Terminal. Le principal problème ici est que nous sommes distribués et installés en tant que "paquet d'application moderne". Ils ont un certain nombre de restrictions et de limitations accidentelles par rapport aux applications natives, mais c'est nécessaire pour Terminal car c'est aussi le moyen le moins difficile d'utiliser les composants de "l'API Windows moderne" (WinRT). C'est terriblement frustrant pour tout le monde dans l'équipe presque tout le temps. :le sourire:

Nous essayons de transformer cette frustration, et celle de la communauté, en progrès pour la plate-forme. Je m'excuse, cependant, ce changement n'est pas rapide ici dans Windows !

@DHowett J'essaie vraiment de comprendre, car j'aime 2/3 Terminal, mais il ne fait pas certaines bases auxquelles je suis habitué avec TakeCommand ou ConEmu, etc.

Je ne peux pas mélanger les élévations dans les différents onglets. Si je comprends bien, c'est parce que vous êtes un autre type d'application et que vous n'hébergez pas vraiment le shell ?

Le tampon de défilement ne s'efface jamais, dans aucun des trois environnements (cmd, PowerShell, wsl bash.) C'est le cas dans mes shells normaux. Encore une fois, à cause de la façon dont il est hébergé ?

Et ce serait plut√īt sympa d'avoir un menu contextuel ou d√©roulant plus accessible. Par exemple, pour effacer ce d√©filement, √©tant donn√© que m√™me l'astuce d'√©chappement de la console n'a pas fonctionn√© pour moi.

L'int√©gration des environnements et la mani√®re dont il r√©cup√®re les shells Linux WSL sont vraiment agr√©ables. Mais cela co√Ľte beaucoup de convivialit√© √† cause des probl√®mes d'√©l√©vation et de d√©filement, donc je l'utilise rarement.

@robomac Il y a un excellent article de @DHowett-MSFT ici qui explique pourquoi nous ne pouvons pas mélanger des onglets élevés et non élevés dans la même fenêtre non élevée.

Le tl;dr est le suivant¬†: si nous permettons aux utilisateurs de se connecter √† des lignes de commande √©lev√©es √† partir d'une fen√™tre de terminal non √©lev√©e, cela cr√©e une faille de s√©curit√© g√©ante, o√Ļ d'autres applications non √©lev√©es pourraient piloter efficacement le processus √©lev√©, via la fen√™tre de terminal.

Je ne sais pas comment ConEmu atténue ce risque, s'ils le font du tout. Il est tout à fait possible qu'il s'agisse d'une faille de sécurité que conemu crée et que nous ne sommes pas à l'aise d'expédier dans le cadre du terminal Windows.

Le reste de vos préoccupations sont tous des problèmes qui sont suivis ailleurs dans ce référentiel, je suggère de les rechercher pour suivre leur progression individuellement. Nous préférerions garder ce fil sur le seul sujet "élévation mixte des onglets"/"avoir un profil qui se lance avec élévation"


Sur le sujet : je souhaite expérimenter la route "lancer une autre instance élevée" pour les profils "élevés". Si l'expérience utilisateur n'est pas trop mauvaise, c'est une voie possible ici, du moins en option.

ConEmu n'att√©nue pas ce risque. Ils transmettent ce risque √† leurs utilisateurs. (Je ne suis m√™me pas s√Ľr qu'ils documentent ce risque.)

Sur le sujet "lancer une autre instance élevée": ce comportement ne me dérangerait pas tant qu'il peut utiliser la même instance élevée de Terminal pour ces onglets et ne pas lancer une nouvelle instance chaque fois que j'invoque un profil "élevé".

À mon avis, la "géantité" de cette faille de sécurité est un peu exagérée. Il n'est pas normal d'avoir un logiciel malveillant sur son ordinateur qui reste assis et attend une chance d'être élevé, donc sacrifier la commodité pour la sécurité ne semble pas juste.

D'un autre c√īt√©, si l'objectif final est que WT soit livr√© avec Windows comme terminal par d√©faut, cela augmenterait consid√©rablement la surface d'attaque. Mais encore une fois, dans ce cas, j'att√©nuerais personnellement un risque en utilisant une alternative impopulaire qui est peu susceptible d'√™tre la cible d'une telle attaque et offre la commodit√© requise (en supposant que la d√©tection de la pr√©sence d'un onglet √©lev√© dans un terminal n'est pas assez triviale √™tre sp√©cifique au terminal).

Une partie de ceci est tl; dr pour moi, mais si vous prenez et videz le package, vous pouvez ex√©cuter wt en dehors du sandboxing, ce qui signifie √©l√©vation, et ex√©cuter sans probl√®me des utilisateurs diff√©rents. J'en avais parl√© √† MSFT √† ignite et on m'avait dit de soumettre une demande d'extraction, mais mes comp√©tences VS sont assez faibles. Ce qui serait assez facile √† faire, c'est de le signer correctement (j'ai d√Ľ le faire avec mon propre pki interne pour que je puisse l'ex√©cuter sur applocker) et de le mettre dans un format distribuable MSI ou MSIX. Il y a un bogue √©trange ici ou l√† qui peut √™tre sp√©cifique √† son ex√©cution de cette fa√ßon, mais dans l'ensemble, cela fonctionne tr√®s bien. Pour l'instant, j'ai juste une fonction pour extraire, signer et remplacer/mettre √† jour une version bas√©e sur les fichiers du programme √† partir de la version bas√©e sur le magasin.

Je comprends le risque de cette fonctionnalité de "brancher" des onglets élevés dans un processus non élevé, mais n'est-il pas possible d'aller dans l'autre sens ?
Pour les gens, à quel point cela est-il nécessaire, laisser le terminal lui-même fonctionner également en mode élevé et permettre de démarrer des onglets non élevés ?
Bien s√Ľr, cela a d'autres inconv√©nients, mais pour moi (et je pense pour d'autres aussi) ils sont acceptables.
(bien s√Ľr, cela pourrait √™tre "int√©ressant" car le terminal est une application Windows Store, je ne sais pas si cela fonctionne)

Ps. Désolé de rouvrir ce problème (également si une autre personne a déjà fait cette suggestion et que je l'ai "relue").

Gr√Ęce √† @EmTschi , j'ai fait une solution simple et 100% pratique
Il utilise le menu contextuel et agit à peu près de la même manière que PowerShell 7
https://github.com/nt4f04uNd/wt-contextmenu
Vous y trouverez un guide sur la façon de l'implémenter et tous les fichiers nécessaires

Merci pour l'astuce, je vais essayer ça plus tard.
Actuellement, je travaille avec deux raccourcis sur mon bureau, qui sont mappés sur les touches Ctrl + Alt + T et Ctrl + Alt + Maj + T pour un terminal élevé, c'est aussi une solution de contournement, mais ... pas aussi agréable comme cela pourrait être et à des kilomètres de quelque chose comme sudo.

@

Chaque fois que j'essaie d'ex√©cuter l'application Terminal avec un compte administrateur, faites un clic droit -> ex√©cuter en tant qu'administrateur, l'UAC appara√ģt deux fois et une erreur se produit en disant¬†:
"Windows ne trouve pas (chemin\WindowsTerminal.exe) Assurez-vous d'avoir tapé...".
Le chemin existe et l'application fonctionne correctement pour l'utilisateur non administrateur qui a créé l'application, mais l'autre utilisateur administrateur ne peut pas l'exécuter.
Si je me connecte à l'utilisateur administrateur, l'application du terminal n'est présente ni dans les paramètres ni dans le menu Démarrer, comme si elle n'avait jamais été installée sur le système.
Existe-t-il un moyen de créer l'application afin qu'elle s'installe pour tous les utilisateurs ? Ou la racine du projet doit-elle se trouver dans un répertoire non spécifique à l'utilisateur ?

Je vois le même problème se produire également.

Version Windows 18922.1000

Je viens d'installer la mise à jour 1909 de Win10 et j'ai le même problème en essayant de m'exécuter en tant qu'administrateur

Même problème ici. Je ne peux pas utiliser le terminal Windows maintenant car j'ai toujours besoin d'exécuter docker et ensuite j'ai toujours besoin d'être administrateur dans le terminal...

J'ai une solution de hack-around pour tous ceux qui le veulent:

  1. téléchargez le msixbundle à partir de la page de publication
  2. décompressez cela, là-dedans, trouvez le msix qui est pour votre plate-forme (généralement celui x64)
  3. décompressez-le dans un dossier quelque part
  4. copiez ce dossier o√Ļ bon vous semble et ex√©cutez WindowsTerminal.exe √©lev√© ou comme bon vous semble

Une grande partie de cet échec semble provenir de la commodité d'avoir cela comme une application de magasin. Il y a une discussion à ce sujet sur # 1386 et quelqu'un a mentionné peut-être l'installation avec Scoop, qui automatise le processus d'extraction ci-dessus.

Ce serait bien si les personnes suivantes étaient traitées comme des citoyens de première classe :

  1. Installations portables (fichiers zip - même si la configuration n'est pas encore portable, car elle se trouve sous AppData\Local lors de l'exécution hors de la zone d'installation du Windows Store)
  2. Un ancien programme d'installation régulier .exe (ou, si vous le devez, .msi) pour les personnes qui ne veulent pas le magasin ou pour utiliser le programme d'installation du magasin

Les deux ne sont pas si difficiles √† mettre en Ňďuvre √† partir de la proc√©dure de construction actuelle, comme en t√©moigne l'automatisation Scoop. Et maintenant que Windows Terminal devient vraiment plut√īt bon, j'aimerais pouvoir l'utiliser comme n'importe quel autre terminal.

Tant qu'on y est : sauf incompatibilités d'API, ce serait bien d'avoir la possibilité d'installer Windows Terminal sans le Store (même de manière "portable") sur les versions antérieures de Windows 10 (mon employeur nous bloque au 1809/ RS5 et l'installation à partir du Store est bloquée).

@sba923 si nous ne nous appuyions pas sur des API qui n'existent qu'en 1903, nous n'aurions pas besoin de 1903.

Bien s√Ľr... c'√©tait ma supposition ūüėú

Devra faire pression pour une mise à niveau à l'échelle de l'entreprise, se heurtera probablement à un mur...

C'est tellement stupide.

Créons un nouveau terminal unifié pour l'invite de commande, powershell et bash pour Windows.
Puis-je exécuter cmd.exe en tant qu'administrateur ?
Non.

Je suppose que je vais simplement garder mes ic√īnes cmd.exe et powershell pr√©d√©finies pour s'ex√©cuter ind√©finiment en tant qu'administrateur sur ma barre des t√Ęches.

image

Des trucs stupides comme celui-ci expliquent pourquoi ma principale machine de travail est toujours un Macbook.

C'est tellement stupide.

Créons un nouveau terminal unifié pour l'invite de commande, powershell et bash pour Windows.
Puis-je exécuter cmd.exe en tant qu'administrateur ?
Non.

Je suppose que je vais simplement garder mes ic√īnes cmd.exe et powershell pr√©d√©finies pour s'ex√©cuter ind√©finiment en tant qu'administrateur sur ma barre des t√Ęches.

Des trucs stupides comme celui-ci expliquent pourquoi ma principale machine de travail est toujours un Macbook.

Je suis d'accord dans ce cas. Je veux une seule fen√™tre de terminal Windows qui h√©berge tous les onglets de terminal dont j'ai besoin, o√Ļ chaque onglet de terminal peut √™tre l'un des multiples h√ītes de terminal install√©s, et √™tre √©lev√© ou non.

Il semble vraiment que cette fonction d'élévation mixte soit freinée par la décision de conception technique d'héberger tous les onglets sur une seule poignée HWND.

1) Pouvez-vous exécuter le nouveau terminal en tant qu'administrateur ? OUI (il y a des problèmes en fonction de la façon dont vous l'avez installé/lancé, mais il n'y a aucun désir que cela ne fonctionne pas). (Si vous ne savez pas comment faire cela, consultez plusieurs messages ci-dessus pour savoir comment.

2) Pouvez-vous avoir un onglet avec une élévation alors qu'un autre ne l'est pas ? Non . Voir https://github.com/microsoft/terminal/issues/632#issuecomment -519375707 pour savoir pourquoi.

Les gens peuvent-ils se rappeler que ce problème concerne les onglets d'élévation mixtes ?! ? Si vous souhaitez lancer l'ensemble du processus en mode élevé et que vous ne pouvez pas, veuillez ouvrir un nouveau problème.

@ DHowett-MSFT Pourrions-nous renommer ce problème pour qu'il concerne les onglets d'élévation mixtes ?

Quelle que soit la manière dont cela est géré ou non, les terminaux ou les onglets surélevés doivent avoir une sorte d'indicateur. Maintenant, si je démarre un nouveau terminal avec Exécuter en tant qu'administrateur, il n'y a aucun moyen de remarquer facilement que mes onglets cmd ont un accès élevé par rapport à ceux de la fenêtre suivante.

EDIT apr√®s le commentaire de @SamuelEnglard¬†: √Čvidemment, j'ai choisi √† la h√Ęte cmd comme mauvais exemple. Oui, cmd affiche "Administrateur¬†:" dans le titre de l'onglet. Mais WSL Ubuntu bash sur mon onglet par d√©faut √©crase tout ce qu'il pourrait y avoir dans son titre d'onglet. Je suppose que bash ne conna√ģt pas (ou m√™me ne se soucie pas) de l'√©l√©vation du terminal Windows, de sorte que ces informations ne peuvent pas √™tre utilis√©es lors de la mise √† jour du titre √† partir de bash (il y a bien s√Ľr sudo situation, mais c'est une autre chose).

Dans profiles.json de Terminal, il y a
"showTabsInTitlebar": false
mais avec ce paramètre, la barre de titre du terminal ne signale pas l'élévation.

@janilahti ne ressemble pas aux onglets CMD élevés
image pour toi?

La sécurité est un point discutable si personne ne veut utiliser votre outil...

Vous devriez simplement créer une commande sudo pour Windows qui fonctionne à la fois dans cmd.exe et powershell. Cela m'éviterait d'avoir un raccourci pour que les deux soient exécutés en tant qu'administrateur.

Pour info, j'ai écrit un sudo for windows , appelé gsudo : https://github.com/gerardog/gsudo

Il prend en charge l'élévation des commandes cmd / powershell / pwsh ou du shell entier. Il est facile à installer et à utiliser et devrait ressembler à l'original *nix sudo. Il existe d'autres implémentations sudo dans la nature, mais à mon humble avis, gsudo est la plus polyvalente et la plus facile à utiliser.

Vous pouvez l'utiliser, par exemple, pour créer un profil WT qui appelle gsudo cmd / gsudo pwsh ou gsudo WhateverShell pour lancer des onglets élevés. Installez gsudo et ajoutez un profil WT :

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

Il s'agit d'une application client-serveur C # qui agit en tant que client lorsqu'elle n'est pas élevée et se lance elle-même en tant que serveur. Les deux instances communiquent via des canaux nommés sécurisés. D'autres sudos Windows dans la nature ressemblent principalement à des scripts "runas" PowerShell qui ouvrent une nouvelle fenêtre, mais le fait d'être une application complète m'a permis d'ajouter beaucoup plus de fonctionnalités.

J'ai lu le fil et la sécurité d'une commande sudo a été discutée et quelques points valables sont faits. J'ai pris toutes les mesures de sécurité auxquelles je pouvais penser et je suis ouvert (et je prévois) d'en introduire d'autres. À ce stade, cela devrait être aussi sécurisé/non sécurisé que si vous ouvriez une session PS d'administration à distance ou si vous faisiez ssh root@server partir d'une console non élevée. (par exemple, vulnérable aux frappes au clavier ou à la mise au rebut de l'écran, et corrigez-moi si je me trompe, mais je crois comprendre que * nix sudo est également vulnérable de cette manière). Il y a aussi le cache des informations d'identification, qui réduit la quantité de popups UAC pendant une session de 5 minutes (inspiré de *nix sudo), qui est clairement un vecteur d'attaque, qui peut être désactivé via config. Pour ceux qui s'inquiètent de la sécurité, je prévois d'ajouter un moyen très simple de le renforcer (en désactivant des fonctionnalités telles que le cache des informations d'identification) avec une simple commande ou via un paramètre de stratégie/registre de groupe d'entreprise.

Un point intéressant soulevé dans ce commentaire est que Microsoft ne peut pas se permettre "d'accepter le risque pour la commodité de l'utilisateur". Si c'est le dernier mot de MS, alors au moins cela ressemble à une solution de contournement décente (entièrement fonctionnelle), et tous les commentaires/ problèmes ou idées sur la façon d'améliorer la sécurité sont les bienvenus.

Il ne peut pas y avoir quelque chose que je dois installer qui n'est pas officiellement pris en charge. Tue toute possibilité de l'utiliser dans un environnement d'entreprise.

Ensuite, @hparadiz , vous devrez attendre la sortie d'une nouvelle version de Windows avec une nouvelle conception de s√©curit√© qui permet un sudo officiel (ou des onglets d'√©l√©vation mixtes) sans risques de s√©curit√©. On dirait que √ßa n'arrivera pas de sit√īt. Votre meilleur coup est d'attendre que l'ensemble du WT puisse √™tre lanc√© en tant qu'administrateur, suivi dans # 4217, susceptible d'√™tre publi√© plus t√īt.

J'ai trouvé un bon hack sur un blog :

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

@gerardog avez-vous un seau de scoop pour gsudo ? ou est-ce dans l'un des connus? Je suis actuellement sur une machine Linux, donc je ne peux pas vérifier.

@fluffynuts C'est dans le r√©f√©rentiel principal de scoop. Donc, juste 'scoop install gsudo'. D'autres m√©thodes d'installation sont √©galement r√©pertori√©es dans https://github.com/gerardog/gsudo . Mais gardons cette discussion sur le sujet WT. ūüėČ

Question ouverte : si c'est un risque pour la sécurité de mélanger des onglets élevés et non élevés, alors ce risque est-il présent dans ConEmu ? Parce qu'il peut faire exactement cela. Ou est-ce que ConEmu implémente cette fonctionnalité d'une manière différente de celle que vous feriez dans Terminal ? Et plus généralement, je noterais que de nombreuses fonctionnalités demandées ici (dans ce fil et d'autres) existent déjà dans d'autres terminaux, ConEmu n'étant qu'un exemple, donc lorsque les développeurs de terminaux suggèrent que ces fonctionnalités ne seraient jamais implémentées ou non implémentées pour depuis très longtemps, vous confirmez implicitement que nous ne devrions pas utiliser Terminal.

si nous ne nous appuyions pas sur des API qui n'existent qu'en 1903, nous n'aurions pas besoin de 1903.

@DHowett-MSFT Existe-t-il une documentation publique disponible concernant les API et pourquoi elles sont nécessaires ? Parce qu'en tant qu'observateur extérieur, quand je vois cette décision et la décision d'utiliser UWP, je ne vois pas la valeur ajoutée. Je vois juste des obstacles à l'ajout de ce que de nombreux utilisateurs d'entreprise considèrent comme des fonctionnalités de base.

@dadpolice Voir https://github.com/microsoft/terminal/issues/632#issuecomment -518888895 pour ce que fait ComEmu.

Je pensais que "UAC n'est pas une barrière de sécurité" selon Microsoft ? Il a été traité comme un dans Vista. Ensuite, on nous a dit que ce n'en était pas un et que tout problème comme celui-ci était une blague dans Windows 7. Maintenant, c'en est encore un aujourd'hui ?

Dans ce cas, vous devrez peut-être revoir la conception de l'explorateur de fichiers et la liste blanche UAC. :)

Ou cela dépend-il simplement du fait qu'il s'agisse ou non d'une excuse pour prendre un raccourci dans la conception de quelque chose que les développeurs normaux ne sont pas autorisés à faire (Explorateur de fichiers) ou de ne pas implémenter une fonctionnalité essentielle (dans ce cas) ?

pas implémenté une fonctionnalité essentielle (dans ce cas) ?

Je veux que ce soit clair - nous n'essayons pas de _pas_ impl√©menter cette fonctionnalit√©. C'est certainement une fonctionnalit√© importante que nous _voulons_ mettre en Ňďuvre. C'est quelque chose que je rencontre quotidiennement en ce moment - avoir une deuxi√®me fen√™tre sur√©lev√©e est _ok_ mais ce n'est pas _bon_.

Il nous faudra juste un certain temps pour √™tre en mesure de concevoir une solution s√©curis√©e de mani√®re appropri√©e, puis de faire l'effort d'ing√©nierie pour la mettre en Ňďuvre. C'est quelque chose que nous avons mis sur tableau blanc pendant un certain temps cette semaine m√™me.

@zadjii-msft

[...]
Je ne pense pas que nous prévoyons de prendre en charge des onglets mixtes élevés et non élevés, car c'est un peu une faille de sécurité.
[...]

(pour ce qui est de lier des discussions connexes, #146)

Bizarre que les gens aient l'impression que la fonctionnalité ne sera pas implémentée. signe de sarcasme

@kort3x Il y a une diff√©rence entre "Pas de plan" (c'est-√†-dire que nous ne le promettons pas) et ne pas vouloir et faire ce qu'ils peuvent faire pour trouver un moyen de le mettre en Ňďuvre.

Comme @zadjii-msft l'a dit :

Il nous faudra juste un certain temps pour √™tre en mesure de concevoir une solution s√©curis√©e de mani√®re appropri√©e, puis de faire l'effort d'ing√©nierie pour la mettre en Ňďuvre. C'est quelque chose que nous avons mis sur tableau blanc pendant un certain temps cette semaine m√™me.

Tant qu'ils n'ont pas de solution sécurisée, ils ne prévoient pas (ou promettent) de prendre en charge les onglets d'élévation mixtes. Je suis prêt à accepter que la seconde qui dispose d'une solution sécurisée l'ajoute au plan (bien que je ne puisse rien promettre).

Je pensais que "UAC n'est pas une barrière de sécurité" selon Microsoft ? Il a été traité comme un dans Vista. Ensuite, on nous a dit que ce n'en était pas un et que tout problème comme celui-ci était une blague dans Windows 7. Maintenant, c'en est encore un aujourd'hui ?

Si je comprends bien, c'est une barrière de sécurité si elle est configurée comme "Toujours notifier", sinon ce n'est pas le cas.

Eh bien, c'est décevant. J'aime le terminal (ce qui en dit long, car je suis assez amoureux des outils non-MS en général), mais l'incapacité d'élever en douceur est un véritable obstacle pour moi de travailler davantage sur ce système d'exploitation.

LOL d'accord oui, je peux voir à quel point c'est déroutant. J'ai initialement écrit ce commentaire quelques jours après notre première annonce, alors qu'il n'y avait pas de plan. Après quelques mois de discussion, je suis certainement venu à l'idée que cela pourrait être possible, avec plus d'efforts. Je vais mettre à jour le commentaire pour refléter cela. @SamuelEnglard a raison cependant, il est difficile de _s'engager_ à le faire jusqu'à ce que nous sachions qu'il est possible de le faire correctement.

C'est encourageant à entendre. Est-il possible d'étendre cet enthousiasme à d'autres équipes, afin que le #3581 puisse être corrigé ?

Ce serait bien si les onglets étaient autorisés à être des processus différents (similaire à la façon dont chrome le gère) en premier lieu, car alors je n'aurais pas à redémarrer tous les onglets après les avoir bien regroupés juste pour obtenir un environnement mis à jour en un seul onglet cmd...
Une fois que le terminal Windows n'est qu'un gestionnaire, il peut s'exécuter en mode non élevé tout en conservant des invites de commande élevées. Ce serait bien. (enfin, avoir le poids élevé tout en tenant des terminaux non surélevés me conviendrait aussi)

@ rapus95 techniquement, les onglets sont, en ce que la "console" est un processus différent. Windows Terminal n'est déjà qu'un gestionnaire

MODIFIER (14 février 2020)
D'accord, donc ce commentaire n'a pas tr√®s bien vieilli. √Ä l'origine, il n'y avait _aucun_ plan pour supporter cela, car cela ne fonctionnerait pas avec le seul HWND que nous avions. Nous travaillons √† la conception d'une solution qui _pourrait_ prendre en charge cela √† l'avenir, mais nous ne pouvons rien nous engager tant que nous ne sommes pas s√Ľrs de pouvoir proposer une solution s√©curis√©e appropri√©e, qui garantit qu'un processus √† privil√®ges inf√©rieurs ne peut pas conduire un terminal √† privil√®ges plus √©lev√©s.

Mis à part quelques autres points, c'est la principale raison pour laquelle j'utilise toujours ConEmu . Et je parie que je le ferai jamais.
https://conemu.github.io/ @Maximus5

C'est tellement stupide.

Créons un nouveau terminal unifié pour l'invite de commande, powershell et bash pour Windows.
Puis-je exécuter cmd.exe en tant qu'administrateur ?
Non.

Des trucs stupides comme celui-ci expliquent pourquoi ma principale machine de travail est toujours un Macbook.

@hparadiz Jetez un Ňďil √† ConEmu :-D Aucun probl√®me pour ex√©cuter plusieurs shells sous forme d'onglets dans UNE fen√™tre¬†; m√™me en ex√©cutant des sessions Powershell et cmd.exe √©lev√©es en dehors des sessions non √©lev√©es.

@tmeckel sommes-nous s√Ľrs que conemu n'a pas les vuln√©rabilit√©s de s√©curit√© qui inqui√®tent l'√©quipe du terminal¬†? les utilisateurs choisissent souvent des logiciels moins s√©curis√©s parce qu'ils font ce qu'ils veulent, mais √† leurs risques et p√©rils.

@drdamour @tmeckel C'est le cas. J'ai posé la même question ci-dessus, il est répondu dans un autre fil: https://github.com/microsoft/terminal/issues/632#issuecomment -518888895

J'ai été assez critique envers Terminal jusqu'à présent, mais pour être juste, ConEmu et ConsoleZ et d'autres outils similaires existent déjà. Il y a peu de valeur à ce que Microsoft les copie simplement, mais il y a une grande valeur à recréer ces fonctionnalités de manière sécurisée. Cela dit, je pense toujours qu'il est très idiot de créer un émulateur de terminal en tant qu'application UWP uniquement pour le Store, surtout maintenant que Microsoft semble s'éloigner de l'UWP (par exemple, le nouveau Edge est une application Win32).

Cela dit, je pense toujours qu'il est très idiot de créer un émulateur de terminal en tant qu'application UWP uniquement pour le Store, surtout maintenant que Microsoft semble s'éloigner de l'UWP (par exemple, le nouveau Edge est une application Win32).

Pour être clair, le terminal n'est pas réservé au magasin ( il y a des fichiers .msix disponibles ici ), ni une application UWP. Il s'agit d'une application Win32 utilisant UWP XAML comme framework d'interface utilisateur.

@ rapus95 techniquement, les onglets sont, en ce que la "console" est un processus différent. Windows Terminal n'est déjà qu'un gestionnaire

Eh bien, pourquoi l'environnement n'est-il pas mis à jour pour une nouvelle instance de cmd ? J'ai toujours besoin d'ouvrir un nouveau terminal Windows, ce qui, dans un certain sens, réduit la convivialité globale d'avoir plusieurs onglets...

@ rapus95 bien que je ne sois pas s√Ľr (je devrais creuser dans le code), je suis √† peu pr√®s s√Ľr que chaque sous-processus est lanc√© avec l'environnement de son parent et non un nouveau.

cela ne semble pas avoir de sens pour un gestionnaire de terminal ūü§Ē

@rapus95 C'est en fait un bug que nous suivons ici : #1125

Pour être clair, le terminal n'est pas réservé au magasin ( il y a des fichiers .msix disponibles ici ), ni une application UWP. Il s'agit d'une application Win32 utilisant UWP XAML comme framework d'interface utilisateur.

Cela ressemble à UWP avec des étapes supplémentaires. Quoi qu'il en soit, je ne peux pas cliquer avec le bouton droit sur Terminal et l'exécuter en tant qu'utilisateur différent, comme je le peux avec n'importe quelle application Win32 normale, c'était un choix étrange.

Ce n'est pas une application UWP ni une application réservée au Store.
Il se trouve que l'une des méthodes de distribution est le Store, qui nécessite un package UWP.
Seuls ceux qui l'ont installé à l'aide du magasin ne peuvent pas Right click -> Run As Admin .
Désinstallez et utilisez le msix ou via scoop

Désinstallez et utilisez le msix ou via scoop

Ou chocolatey .

@gerardog Je n'ai pas dit exécuter en tant qu'administrateur, j'ai dit exécuter en tant qu'utilisateur différent.

Shift + Right Click ne vous convient-il pas ?
image
(Veuillez noter que j'ai installé en utilisant scoop )

Non. J'ai installé le package msix et cette option n'existe pas.

J'ai installé en tant que chocolatey et je n'ai pas exécuté en tant qu'administrateur non plus

Pour être clair, le terminal n'est pas réservé au magasin ( il y a des fichiers .msix disponibles ici ), ni une application UWP. Il s'agit d'une application Win32 utilisant UWP XAML comme framework d'interface utilisateur.

Cela ressemble à UWP avec des étapes supplémentaires. Quoi qu'il en soit, je ne peux pas cliquer avec le bouton droit sur Terminal et l'exécuter en tant qu'utilisateur différent, comme je le peux avec n'importe quelle application Win32 normale, c'était un choix étrange.

Pareil ici, j'ai essayé à la fois msix et store app. Je n'ai toujours pas l'option "Exécuter en tant qu'utilisateur différent".

Qu'en est-il de rendre la couleur d'arrière-plan de tous les onglets élevés rouge afin qu'il soit évident qu'il est élevé ?

Je préfère avoir ceci paramétrable : couleur de fond, titre de l'onglet...

https://github.com/gerardog/gsudo fonctionne bien comme solution temporaire

Peut-être implémenter quelque chose comme wt elevated qui ouvre une nouvelle fenêtre élevée avec le shell actuel avec le même environnement.
EDIT : ou #3158 mais comme nouvelle fenêtre et élevée

Je ne comprends pas pourquoi vous ne copieriez pas comme le fait Linux.

À ma connaissance ou dans le monde Linux (corrigez-moi si je me trompe), les applications de terminal (gnome-terminal, mate-terminal ...) n'ont pas besoin d'être élevées même si vous tapez su ou sudo et exécutez la commande comme le utilisateur racine. La seule mission de l'application terminal est d'exécuter un shell dans un processus différent (bash, ksh...) élevé ou non, et de rediriger l'entrée et la sortie du shell afin que nous puissions interagir avec le shell.

Si vous tapez "su" ou commencez une commande avec "sudo" dans un terminal Linux, cela n'ouvrira pas une autre fenêtre.

@gabsoftware Je ne suis pas s√Ľr de la s√©curit√© de cela, m√™me sous Linux. Il est √©galement possible d'envoyer des frappes aux fen√™tres X sous Linux, et je suppose qu'il est possible d'envoyer des frappes aux clients de terminal s'ex√©cutant dans une fen√™tre X m√™me si le terminal en cours d'ex√©cution est √©lev√© avec sudo ou su. Il peut m√™me √™tre possible d'envoyer des frappes √† des fen√™tres X √©lev√©es, mais je n'en suis vraiment pas s√Ľr.

Pour être clair, le terminal n'est pas réservé au magasin ( il y a des fichiers .msix disponibles ici ), ni une application UWP. Il s'agit d'une application Win32 utilisant UWP XAML comme framework d'interface utilisateur.

Cela ressemble à UWP avec des étapes supplémentaires. Quoi qu'il en soit, je ne peux pas cliquer avec le bouton droit sur Terminal et l'exécuter en tant qu'utilisateur différent, comme je le peux avec n'importe quelle application Win32 normale, c'était un choix étrange.

Pareil ici, j'ai essayé à la fois msix et store app. Je n'ai toujours pas l'option "Exécuter en tant qu'utilisateur différent".

Je ne peux pas "Exécuter en tant qu'utilisateur différent" en cliquant avec le bouton droit sur la vignette dans le menu Démarrer, mais je peux si je clique avec le bouton droit sur WindowsTerminal.exe

@gabsoftware Je ne suis pas s√Ľr de la s√©curit√© de cela, m√™me sous Linux. Il est √©galement possible d'envoyer des frappes aux fen√™tres X sous Linux, et je suppose qu'il est possible d'envoyer des frappes aux clients de terminal s'ex√©cutant dans une fen√™tre X m√™me si le terminal en cours d'ex√©cution est √©lev√© avec sudo ou su. Il peut m√™me √™tre possible d'envoyer des frappes √† des fen√™tres X √©lev√©es, mais je n'en suis vraiment pas s√Ľr.

J'ai fait quelques exp√©riences, et maintenant je suis plut√īt s√Ľr de l' ins√©curit√© de cela sous Linux. Je ne suis pas un expert en s√©curit√©, donc je ne suis pas s√Ľr des implications de cela (quelqu'un?). Il s'av√®re qu'il est tr√®s facile d'envoyer des frappes aux fen√™tres X qui viennent d'ex√©cuter sudo et sont ouvertes aux nouvelles commandes sudo sans demander de mot de passe. Article de blog ici , d√©sol√© pour la prise honteuse...

Ma conclusion serait qu'à moins qu'il n'y ait un moyen d'interdire l'envoi de frappes aux fenêtres à élévation mixte, cela ne devrait être implémenté qu'en tant qu'option pour les utilisateurs prêts à accepter le risque (gros panneaux d'avertissement, etc.).

En passant, comment le clavier à l'écran de Windows envoie-t-il des frappes aux fenêtres surélevées ?

J'ai publié gsudo v0.7 et est pertinent pour ce fil :

EDIT : Pour le contexte : gsudo est un sudo pour Windows, et permet d'élever une commande simple ou un shell dans la console actuelle. Lorsqu'il est invoqué à partir d'un Cmd/Pwsh dans WT, il élève l'onglet. En outre, vous pouvez modifier votre profil, le nommer 'Elevated Powershell' et changer votre commande en gsudo Powershell et voilà, vous avez un profil d'onglet élevé. Voir ici .

Mais depuis que gsudo, ou n'importe quel sudo pour Windows, saute par-dessus l'isolation UAC, il a été étiqueté "non sécurisé". Ce qui suit est une solution de contournement plus compliquée qui vous permet de faire des élévations mixtes d'onglets tout en gardant la sécurité. /FIN EDIT

gsudo peut maintenant lancer des applications avec n'importe quel niveau d'int√©grit√©. Par exemple, nous pouvons lancer Windows Terminal avec le niveau d' int√©grit√© MediumPlus , c'est-√†-dire un mode "semi-√©lev√©": aucun droit d'administrateur mais isol√©, inaccessible aux autres processus r√©guliers (int√©grit√© moyenne). (une fen√™tre contextuelle UAC appara√ģtra)

Donc, la première étape devrait être de toujours lancer WT avec : gsudo -i MediumPlus WT
(Vous pouvez changer votre raccourci WT). Cela protège WT des processus malveillants, du scrapping d'écran, des sendkeys, de l'injection de dll, etc.
(EDIT : si cela ne fonctionne pas, utilisez : gsudo -n -i MediumPlus cmd /c cmd /c start wt )

Ensuite, vous pouvez utiliser gsudo en toute sécurité dans WT pour élever les commandes, ou même créer un profil élevé avec : "commandline": "gsudo cmd.exe" dans profiles.json

Ma conclusion serait qu'à moins qu'il n'y ait un moyen d'interdire l'envoi de frappes aux fenêtres à élévation mixte... cela ne devrait être implémenté qu'en tant qu'option pour les utilisateurs prêts à accepter le risque (gros panneaux d'avertissement, etc.).

Fait et fait. (J'ai ajouté des avertissements de sécurité à gsudo).

De plus, depuis que j'ai appris que si l'utilisateur invoque gsudo à partir d'un processus d'intégrité normal/moyen , le cache des informations d'identification de gsudo (la fonctionnalité permettant d'afficher moins de fenêtres contextuelles UAC) ne peut jamais être entièrement protégé... Donc, maintenant les informations d'identification le cache doit être explicitement activé via gsudo cache on/off ou gsudo config cachemode auto .

Il s'avère que "Changing your WT shortcut" n'est pas du tout trivial : étant donné le modèle MSIX/AppStore, vous avez rencontré #4217 et #4459.

Le script powershell suivant contourne ces problèmes pour créer un raccourci Windows Terminal sur le bureau et l'associe au raccourci clavier 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()

Une fois que vous avez démarré WT en tant que MediumPlus (c'est-à-dire Ctrl + Alt + T), vous pouvez utiliser gsudo comme mentionné [ci-dessus] (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) pour élever les commandes dans ce que AFAIK devrait être en sécurité.

Ma solution consiste à utiliser _Sudo pour Windows_ de Luke Samson . La configuration du profil est :
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
Lorsque vous d√©marrez un nouvel onglet avec ce profil, UAC appara√ģt, puis vous vous retrouvez dans un noyau Powershell √©lev√©. Fonctionne √©galement avec n'importe quel autre terminal.
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
Si vous n'utilisez pas scoop , je suis s√Ľr que le concept peut √™tre extrait et utilis√© ind√©pendamment. Consultez le code source ici¬†: https://github.com/lucesampson/psutils/blob/master/sudo.ps1

J'utilise la solution de contournement schtasks pour exécuter Windows Terminal en tant qu'administrateur et contourner l'UAC :

  1. D√©marrez le planificateur de t√Ęches.
  2. Cr√©ez une nouvelle t√Ęche. Donnez-lui un nom et cochez la case "Ex√©cuter avec les privil√®ges les plus √©lev√©s".
    image
  3. Dans l'onglet Actions, sélectionnez pour démarrer un programme : wt

  4. Dans l'onglet Param√®tres, assurez-vous que "Autoriser l'ex√©cution de la t√Ęche √† la demande" est coch√© et d√©cochez la case "Arr√™ter la t√Ęche si elle s'ex√©cute pendant plus de".

  5. Créez un raccourci en cliquant avec le bouton droit sur le bureau et sélectionnez Nouveau -> Raccourci et tapez schtasks.exe /run /TN "{task name}"
    image
  6. Modifiez √©ventuellement l' ic√īne de raccourci et faites-la glisser vers la barre des t√Ęches.

On dirait que je vais devoir m'en tenir à cmder jusqu'à ce que ce soit corrigé.

maintenant qu'il y a une idée d'un plan supposé, pouvons-nous obtenir les docs
mis à jour pour ne plus dire qu'il n'y a pas de plan actuel ?

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

@drdamour Une fois qu'il y a un plan, j'aimerais supprimer cette section. Pour le moment cependant, il n'y a qu'un plan pour rechercher un moyen de faire un plan. Une fois qu'il y aura un vrai plan et une façon de le faire en toute sécurité, je supprimerai cette section.

La méthode décrite par @KMoraz fonctionne très bien comme solution de contournement pour le moment. Merci d'avoir posté ceci.

Salut les gens,

J'utilisais ConsoleZ jusqu'à ce que je découvre celui-ci hier.
ConsoleZ a quelques fonctionnalit√©s et l'une consiste √† d√©marrer un nouvel onglet en tant qu'administrateur √† l'aide de l'UAC (la bo√ģte de dialogue de l'UAC appara√ģt).
Je trouve cela très utile car vous n'avez pas besoin de prendre les mains du clavier pour ouvrir un nouvel onglet surélevé.

Et s'il s'agissait d'une configuration dans la configuration du profil ? C'est comme ça que ça se passe dans ConsoleZ.

Salut tout le monde,

J'ai trouvé une autre solution de contournement de raccourci qui est simple et fonctionne très bien pour ceux qui doivent entrer les informations d'identification de l'administrateur local lors de l'exécution de quoi que ce soit en tant qu'administrateur.

Ce lien explique, mais nécessite un chemin complet pour la référence wt.exe :
http://nuts4.net/post/windows-terminal-run-as-admin

Ma cha√ģne de raccourci compl√®te est¬†: C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

MISE À JOUR 21 mai 2020 :
Ce qui précède fonctionnait avant la version 1.0.1401.0.

Voir aussi ce nouveau numéro : https://github.com/microsoft/terminal/issues/6013

Maintenant, le clic Crtl-Shift ne fonctionne PAS non plus lorsque vous devez élever avec un compte administrateur local.

Voir la capture d'écran d'erreur ci-dessous que je reçois après avoir été invité deux fois pour les autorisations d'élévation :
Error

Pour information, à mon humble avis gsudo est parfait pour cela, merci https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

Ma config n'a que ce profil pour avoir le privilège :

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

Pour moi, le moyen le plus simple d'ouvrir Windows Terminal en tant qu'administrateur est de l'√©pingler en tant que premier √©l√©ment de la barre des t√Ęches. Puis Win+Ctrl+Shift+1 l'ouvre en tant qu'administrateur

Pour moi, le moyen le plus simple d'ouvrir Windows Terminal en tant qu'administrateur est de l'√©pingler en tant que premier √©l√©ment de la barre des t√Ęches. Puis Win+Ctrl+Shift+1 l'ouvre en tant qu'administrateur

En effet très pratique, mais cela ne fonctionne que pour les comptes membres du groupe Administrateurs.

Si vous agissez en tant qu'administrateur pour quelqu'un d'autre, vous ne pourrez pas exécuter Windows Terminal en tant qu'utilisateur (administrateur) à partir de son compte.

Je pense que ce serait bien d'avoir une configuration d'onglet pour exécuter cmd en tant qu'administrateur, pas tout.

Je pense que ce serait bien d'avoir une configuration d'onglet pour exécuter cmd en tant qu'administrateur, pas tout.

Comme expliqué ailleurs ici, cela n'est pas possible avec la conception actuelle.

existe-t-il un drapeau qui peut être utilisé pour s'exécuter en tant qu'administrateur ? Ensuite, nous pourrions simplement créer un raccourci pour cela.

Si vous √©pinglez le terminal Windows √† la barre des t√Ęches, vous pouvez le lancer _√©lev√©_ en utilisant Ctrl+Maj+clic.

Cela fera la m√™me chose qu'un clic droit sur l'ic√īne, un clic droit sur "Terminal Windows", suivi de "Ex√©cuter en tant qu'administrateur".

Remarque : Windows Terminal étant une application Store, vous ne pouvez pas l'exécuter en tant qu'_autre utilisateur_.

J'aimerais voir la possibilité d'avoir des "onglets de niveau d'intégrité mixte" dans Windows Terminal, avec le niveau d'intégrité en option dans chaque profil. Il s'agit principalement d'une commodité dans mon travail normal d'administrateur système/devops pour minimiser les interruptions de flux de travail et le changement de contexte.

J'ai trouv√© une alternative simple qui fonctionne pour moi pour l'instant. Cela ne r√©sout pas tous les sc√©narios pr√©sent√©s ici par d'autres utilisateurs. Cela ne d√©pend pas des applications tierces, des fichiers de raccourcis, des combinaisons de touches ou des t√Ęches planifi√©es. Il n'est pas n√©cessaire d'identifier l'emplacement de l'ex√©cutable du terminal Windows. Il cr√©e simplement une entr√©e distincte dans la liste des profils Windows Terminal qui lance une deuxi√®me instance Windows Terminal √©lev√©e. Cela d√©clenche une fois une invite UAC. Je ne l'utilise que si et quand j'ai besoin d'√©l√©vation.

Le résultat est deux terminaux Windows. Tout ce qui est dans l'un est standard et tout ce qui est dans l'autre est élevé. Pour moi, c'est un niveau acceptable d'interruption et de changement de contexte. Le terminal Windows élevé ajoute également au début de chaque titre d'onglet "Administrateur :", ce qui donne une bonne confirmation visuelle de la différence.

Edit : J'ai installé Powershell 7,

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

@IarwainBen-adar, il me semble me souvenir d'avoir récemment lu dans la nouvelle documentation que vous ne pouvez pas utiliser l'élément commandline et l'élément source ensemble. Cela fonctionne-t-il comme prévu sans l'élément source ?

J'ai essay√© son code et je n'arrive m√™me pas √† faire appara√ģtre le nouvel √©l√©ment dans le pull
menu vers le bas.

@shem-sargent d√©sol√© √† ce sujet, j'ai supprim√© mon commentaire ici parce que la d√©claration superflue source √©tait en effet le probl√®me. Bien que, maintenant que l'entr√©e de menu fonctionne, je ne peux malheureusement toujours pas lancer une instance √©lev√©e de Windows Terminal - je rencontre le probl√®me n ¬į 3145 avec un √©chec de The file cannot be accessed by the system.

@IarwainBen-adar D√©sol√©, je ne peux pas reproduire #3145. Sinon, j'essaierais de r√©soudre le probl√®me de mon c√īt√©.

√©pingler √† la barre des t√Ęches et Maj + clic droit

Bravo @LordFPL et bien s√Ľr @gerardog , je n'avais jamais entendu parler de gsudo (https://github.com/gerardog/gsudo pour les autres int√©ress√©s) auparavant, mais cela rend les sessions sur√©lev√©es un jeu d'enfant maintenant. Merci! Ajoutez-le √† l'objet de profil dans le fichier de param√®tres ou utilisez simplement l'alias sudo comme vous le feriez sur un syst√®me Linux. Parfait!

@zadjii-msft mes excuses, mais je ne comprends pas exactement quel est le problème ici. Windows prend en charge la manipulation et l'emprunt d'identité des jetons, c'est ainsi que fonctionnent les runas, n'est-ce pas ? en utilisant gsudo de @gerardog, je peux avoir un wt d'intégrité (plus faible) hébergeant un shell d'intégrité (plus) élevé en même temps que tout autre shell d'intégrité de niveau, que ce soit powershell, pwsh, cmd ou n'importe quel shell wsl. D'après mes tests limités, aucun des shells à faible intégrité ne peut déboguer dans ce shell à intégrité supérieure. Quel est le barrage routier ici pour avoir ceci en tant que terminal intégré, ou encore plus préférable au niveau du système d'exploitation, fonctionnalité ?

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

Une fen√™tre d'int√©grit√© (plus faible) _recevant une entr√©e et la canalisant directement dans un processus d'int√©grit√© (plus) √©lev√©e_ ouvre ce processus d'int√©grit√© (plus) √©lev√©e au contr√īle par d'autres √©l√©ments d'int√©grit√© (plus) faible sur le syst√®me.

Cela signifie qu'un processus potentiellement malveillant n'a besoin que d'un déplacement latéral au même niveau de privilège pour obtenir l'EoP.

@smokeintheshell #632 (commentaire)

Une fen√™tre d'int√©grit√© (plus faible) _recevant une entr√©e et la canalisant directement dans un processus d'int√©grit√© (plus) √©lev√©e_ ouvre ce processus d'int√©grit√© (plus) √©lev√©e au contr√īle par d'autres √©l√©ments d'int√©grit√© (plus) faible sur le syst√®me.

Cela signifie qu'un processus potentiellement malveillant n'a besoin que d'un déplacement latéral au même niveau de privilège pour obtenir l'EoP.

oui, j'ai lu cette explication au début du fil, mais je ne comprends pas pourquoi c'est bon pour Linux, et probablement Mac, mais pas pour Windows ? Windows protège actuellement l'entrée des processus élevés contre les processus non élevés. Dans ce problème ou dans un problème connexe, quelqu'un a suggéré que nous ayons besoin d'un processus distinct par onglet. Je pense que c'est déjà le cas puisque chaque onglet a sa propre commande à exécuter (par exemple : pwsh.exe). Est-ce parce qu'ils sont tous des enfants du même processus racine sous un HWND ?

Le terminal d'Ubuntu souffre-t-il du même problème avec les onglets si je:

  • avoir un onglet avec su ouvert
  • avoir un onglet o√Ļ j'ai d√©j√† √©lev√© avec sudo et je n'ai pas besoin d'entrer √† nouveau mon PW par politique de configuration¬†?

Ou l'architecture d'Ubuntu est-elle en quelque sorte renforcée contre les attaques par injection d'entrée inter-processus?

Le terminal d'Ubuntu souffre-t-il du même problème avec les onglets si je:

* 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 l'architecture d'Ubuntu est-elle en quelque sorte renforcée contre les attaques par injection d'entrée inter-processus?

Si vous regardez mon commentaire ici , j'ai en fait reproduit/exploité le problème sous Linux. su et sudo sont probablement également "vulnérables", en ce sens que vous pouvez envoyer des frappes à des fenêtres d'intégrité inférieure exécutant ces commandes. Le délai d'attente du mot de passe sudo (ne pas avoir à saisir votre mot de passe à la prochaine commande sudo dans les 15 minutes) rend cela encore plus facile. Vous pouvez renforcer Ubuntu en désactivant l'extension X nécessaire à l'attaque. Je ne sais pas si cela est possible dans un environnement Wayland (l'attaque et/ou le durcissement).

Je comprends parfaitement la décision de ne pas implémenter les onglets à élévation mixte, à moins qu'il existe un moyen de désactiver les claviers virtuels et d'autres méthodes de saisie logicielle.

Je pense que c'est déjà le cas puisque chaque onglet a sa propre commande à exécuter (par exemple : pwsh.exe). Est-ce parce qu'ils sont tous des enfants du même processus racine sous un HWND ?

@kbirger Oui, il existe des processus distincts pour chaque onglet, mais toutes vos entrées de souris et de clavier sont toujours envoyées à la fenêtre du terminal Windows (qui est de faible intégrité), puis acheminées vers chaque processus shell via des flux d'entrée standard. C'est ainsi que fonctionnent tous les raccourcis clavier de Windows Terminal.


Je me demande s'il est possible de détecter si l'entrée est forgée, par exemple en utilisant l'API GetCurrentInputMessageSource . Je ne trouve pas beaucoup d'informations sur cette API autre que l' exemple officiel, mais à partir de la description, il devrait être en mesure d'identifier la source d'entrée (matériel/des processus avec uiAccess, principalement des logiciels d'accessibilité/des processus sans uiAccess, peut-être malveillant)

pourquoi c'est bon pour Linux, et probablement Mac, mais pas pour Windows ?

Je suis presque s√Ľr que l'une des trois raisons est que Microsoft vend la s√©curit√© en tant que fonctionnalit√© √† d'autres grandes entreprises ou gouvernements.

Il y a aussi quelques autres réponses qui me viennent à l'esprit pour expliquer pourquoi cela n'a peut-être pas été un problème jusqu'à présent :

  • Pendant longtemps, et pour de nombreuses raisons (telles que les "hackers" n'aimant pas Windows, et "tout le monde" utilisant Windows ^^), Windows a √©t√© la cible principale (‚Čąseule) de toutes sortes de logiciels malveillants. Il avait besoin d'une meilleure s√©curit√© (prot√©ger les fen√™tres sur√©lev√©es), tandis que d'autres s'en fichaient.
  • Comme expliqu√© pr√©c√©demment dans ce probl√®me, il n'aurait pas d√Ľ √™tre possible pour les logiciels malveillants d'acc√©der facilement √† votre h√īte de console √©lev√© sous Windows, il est donc probable que peu d'entre eux aient investi dans ce probl√®me (je ne suis pas un expert en s√©curit√©, donc je ne sais pas si certains l'ont)
  • Les logiciels malveillants ont g√©n√©ralement eu d'autres moyens de s'√©lever que d'essayer de trouver une invite de commande √©lev√©e dans le syst√®me d'exploitation de votre choix
  • Seuls les d√©veloppeurs et les administrateurs syst√®me utilisent des terminaux (cela ne fait que r√©duire la cible d√©mographique de l'attaque¬†; les gouvernements et les grandes entreprises sont toujours une pr√©occupation)

Maintenant, en introduisant la fonctionnalit√© na√Įvement (comme nous l'aurions tous fait, j'en suis s√Ľr ūüėĄ), vous introduiriez une nouvelle (√©norme) faille dans certaines installations de Windows. Le d√©veloppement √©tant effectu√© √† l'air libre, vous pouvez √™tre s√Ľr que tous ceux qui en ont besoin seraient conscients de la faille et commenceraient √† coder pour la corriger.
La contre-mesure rapide √©tant d'interdire Windows Terminal (et probablement tous les autres √©mulateurs de terminaux maintenant que la faille est publique), vous pourriez alors dire adieu √† vos r√™ves d'utiliser Windows Terminal dans n'importe quel type d'environnement d'entreprise ūüėü

J'esp√®re toujours qu'une version s√©curis√©e de cette fonctionnalit√© verra le jour, cependant ūü§ě

Je vois. Merci pour les explications !

En passant, comment le clavier à l'écran de Windows envoie-t-il des frappes aux fenêtres surélevées ?

@mrwensveen AFAIK, il existe trois façons d'envoyer des entrées à des fenêtres surélevées :

  1. √Člevez-vous. Cependant, vous ne pouvez toujours pas envoyer d'entr√©es aux processus syst√®me (par exemple, le gestionnaire de t√Ęches, la bo√ģte de dialogue UAC, l'√©cran de connexion).
  2. Enregistrez un service Windows. Maintenant, votre programme s'exécute en tant que SYSTEM afin que vous puissiez faire tout ce que vous voulez. J'ai vu certains programmes d'accès à distance faire cela.
  3. D√©clarez le drapeau uiAccess , signez num√©riquement votre binaire, installez √† un emplacement qui n'est pas accessible en √©criture pour l'utilisateur actuel. C'est une "porte d√©rob√©e" pour les logiciels d'accessibilit√©, leur permettant de lire/√©crire n'importe quel autre programme (y compris les processus syst√®me) et de s'afficher au-dessus de toutes les autres fen√™tres (y compris Secure Desktop o√Ļ les fen√™tres contextuelles UAC s'affichent et l'√©cran de connexion), le tout sans ex√©cution √©lev√©e. Voir https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

Le clavier à l'écran (osk.exe), Narrator.exe (et peut-être d'autres lecteurs d'écran) utilisent tous la méthode 3.

image
(Une capture d'écran montrant le manifeste du programme intégré de osk.exe avec uiAccess=true )


On dirait que le drapeau uiAccess peut également empêcher l'accès au programme par d'autres programmes à faible intégrité (bien qu'il fonctionne toujours sans élévation), peut-être pouvons-nous utiliser cette "fonctionnalité" pour protéger WT ?

@yume-chan Cool, c'est très intéressant, merci ! Les uiAccess sont-ils autorisés à envoyer des frappes à d'autres uiAccess ? Nous voulons toujours qu'OSK puisse interagir avec le terminal Windows, et si cela signifie que d'autres programmes doivent au moins être signés avant qu'il ne soit autorisé à envoyer des entrées au terminal Windows, est-ce une barrière suffisamment élevée ?

Les programmes uiAccess sont-ils autorisés à envoyer des frappes à d'autres programmes uiAccess ?

@mrwensveen Oui, les programmes avec le privilège uiAccess peuvent accéder les uns aux autres.

Je préfère la méthode API GetCurrentInputMessageSource (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562) car ce n'est pas l'utilisation prévue uiAccess . De plus, avec l'API, nous pouvons toujours autoriser les programmes à faible intégrité à envoyer des frappes à des onglets non élevés, mais pas à des onglets élevés.

Petite solution de contournement que j'ai faite ici:

J'ai install√© PowerToys qui a des fonctionnalit√©s int√©ressantes. L'un d'eux consiste √† afficher les raccourcis Windows et j'ai d√©couvert que lorsque vous appuyez sur Win + num√©ro, l'application s'ouvre dans la barre Windows correspondant au num√©ro qui appara√ģt dans la barre.

Donc, j'ai mis le terminal dans la barre comme premi√®re ic√īne
image .

Lorsque j'appuie sur Win + 1, le terminal s'ouvre.

image

Lorsque j'appuie sur Win + Ctrl + Maj + 1, il s'ouvre en hauteur.

image

Je mettrai également ma configuration de terminal et mon profil powershell ici si vous voulez obtenir les fonctionnalités d'affichage de la branche git et de l'environnement conda dans l'invite et l'utilisateur en rouge s'il s'agit d'un terminal élevé ...

Cela existe depuis au moins Windows 7 ; ce n'est pas une chose PowerToys.

@Firehawke Oui, je viens de découvrir à cause de PowerToys ... ce n'est pas nécessaire.

Voici un profil pour le lancement d'√©l√©vation qui fonctionne sur Windows Store et qui a une ic√īne appropri√©e¬†:

{
    "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 : Merci à @glooms , @shem-sargent, @LordFPL et @Firehawke pour les différents composants de cet extrait. Comme cette commande appelle pwsh.exe , il semble que certaines personnes aient rencontré #4228 (une erreur 0x80070002 lors du lancement) en raison de variables d'environnement PATH corrompues ou de binaires étranges dans leur chemin nommés powershell.exe ou pwsh.exe . @zurkz a corrigé cela en faisant référence powershell.exe , mais je ne pense pas que ce soit fiable maintenant. #6684 résout ce problème pour Windows Terminal, et vous trouverez une version corrigée ci-dessous, suivant cette solution, qui ne devrait pas du tout avoir ce problème.

Voici un profil pour le lancement d'√©l√©vation qui fonctionne sur Windows Store et qui a une ic√īne appropri√©e¬†:

{
    "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 Ça marche bien ! Merci.

Voici un profil pour le lancement d'√©l√©vation qui fonctionne sur Windows Store et qui a une ic√īne appropri√©e¬†:

{
    "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 ‚̧ūüíĮ

Voici un profil pour le lancement d'√©l√©vation qui fonctionne sur Windows Store et qui a une ic√īne appropri√©e¬†:

{
    "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 Pardonnez mon ignorance, cela est-il supprim√© dans la configuration du Windows Store? Si oui, quelqu'un peut-il poster le chemin? Sinon, o√Ļ est-ce que ce mauvais gar√ßon est cens√© vivre ?

TYIA !

@Kazamario
Il va dans le fichier settings.json du terminal Windows, dans la section des profils.

Il provoque une erreur : 0x80070002 lors du lancement. psh 7.1.

Je l'ai changé en :

{
    "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"
}

et UAC invité à élever les autorisations.

Je l'ai changé en :

{
    "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"
}

et UAC invité à élever les autorisations.

cela a plut√īt bien fonctionn√© pour moi. Merci!

Voici comment démarrer Windows Terminal élevé s'il a été épinglé au démarrage.
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@narfanar Il semble que vous ayez rencontr√© # 4228, o√Ļ le terminal Windows √©met une erreur 0x80070002 au d√©marrage lorsque la variable d'environnement PATH est foir√©e ou que d'autres fichiers binaires flottent dans le chemin nomm√© powershell.exe ou pwsh.exe . Je ne pense pas que l'extrait de code de @zurkz corrige vraiment cela, car il ne fait que d√©placer les probl√®mes potentiels de pwsh.exe √† powershell.exe . #6684 a corrig√© cela pour WT, voici donc un extrait ajust√© √† cette solution¬†:

{
    "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 le fait bien

Notez que Cmder a cette fonctionnalité, qui est incroyablement utile. J'adorerais le voir implémenté dans Windows Terminal. Même s'il doit lancer une fenêtre séparée pour les onglets d'administration ou quelque chose du genre.

mon profil par d√©faut est d√©fini sur bash plut√īt que sur powershell, et j'aimerais que cela reste ainsi. l'extrait ci-dessus fonctionne tr√®s bien, mais j'adore pouvoir lui faire lancer un nouveau terminal sur√©lev√© avec le profil powershell charg√©. J'ai pass√© environ 3 heures √† essayer de comprendre cela (pas un grand fan de / j'ai beaucoup d'exp√©rience avec PowerShell) et je n'arrive pas √† le comprendre - s'il vous pla√ģt, aidez-moi. il semble qu'il y ait une combinaison de guillemets simples, de guillemets doubles, d'√©chappement, d'espaces, de sauts de ligne, qui pourraient le faire fonctionner, mais je ne peux pas obtenir le processus de d√©marrage et la liste d'arguments pour faire ce que je veux. je l'ai r√©sum√© √†:

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
cela fonctionne dans un fichier .ps1 si je l'exécute moi-même, j'obtiens un nouveau terminal Windows élevé avec le profil powershell chargé. mais cela ne fonctionne pas dans le paramètre de ligne de commande de settings.json, peu importe comment j'essaie de le modifier, en appelant explicitement argumentlist au lieu d'utiliser cmd /c, diverses formes d'échappement et d'utilisation des guillemets, etc.

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
ne marche pas. le mieux que je puisse faire est de lui faire lancer un étrange hybride de ce que je veux. Je vais charger une fenêtre "Administrateur: Ubuntu", qui ressemble à mon profil bash mais qui exécute en fait PowerShell. mauvaise police et tout. si j'utilise cette fenêtre pour ouvrir un nouvel onglet powershell, il sera élevé comme vous le souhaitez. quand c'est comme ça, je peux coller toutes les ordures que je veux dans la partie "Windows PowerShell" du chargement du profil et j'obtiens exactement le même comportement, donc je sais qu'il n'essaie pas vraiment de charger le profil que je lui passe.

J'ai donc un problème en essayant de continuer à exécuter ceci en mode élevé, j'ai fait toutes les options répertoriées ci-dessus et j'obtiens soit l'erreur "Impossible de trouver le fichier", soit ceci.

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

Quelqu'un d'autre a-t-il encore le problème ou n'a-t-il pas réussi à les faire fonctionner correctement?

mon profil par d√©faut est d√©fini sur bash plut√īt que sur powershell, et j'aimerais que cela reste ainsi.

Moi aussi. J'exécute WSL la plupart du temps, mais de temps en temps, j'ai besoin d'exécuter PS en mode élevé, et j'aimerais le faire dans un onglet du nouveau WT.

Je n'ai pas non plus réussi à faire fonctionner aucun des exemples - même en corrigeant mes chemins de fichiers. J'ai trouvé et installé gsudo qui peut élever l'onglet actuel, ou être utilisé comme profil pour ouvrir un onglet élevé dans la même fenêtre. Je ne sais pas si les solutions ci-dessus ont commencé dans une nouvelle fenêtre (certaines tentatives que j'ai faites avant d'utiliser gsudo ne commenceraient que dans une nouvelle fenêtre). Cela ouvrira une fenêtre contextuelle UAC.

Voici le profil que j'utilise :

{
    // 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
}

J'utilise supressApplicationTitle pour que le titre de l'onglet n'affiche pas Administrator: car il est redondant avec Elevated .

@ayfine Si https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 ne fonctionne effectivement pas pour vous, pourriez-vous envoyer une transcription des erreurs/comportements inattendus exacts que vous obtenez avec cette configuration¬†? (Assurez-vous d'ajouter une configuration suppl√©mentaire, comme suppressApplicationTitle , en √©tapes aussi petites que possible, de sorte que si l'une de vos configurations casse WT, il sera plus facile de dire o√Ļ et quand cela se produit.)

Si d'autres configurations ici sont légèrement plus avancées que celle liée pour vous, des détails sur la façon dont celles-ci se cassent seraient également appréciés.

@ bb010g Je ne rencontre aucun message d'erreur - mes excuses pour ne pas avoir été plus précis dans ma réponse. Lors de l'utilisation de https://github.com/microsoft/terminal/issues/632#issuecomment -663686412, j'ai rencontré le problème du terminal Windows chargeant mon shell WSL Ubuntu (mon shell par défaut). J'avais pris cela à l'origine pour signifier que cela ne fonctionnait pas correctement, mais je vois maintenant que dans cette nouvelle fenêtre, si je démarre un nouvel onglet Powershell (profil par défaut), il est en fait élevé. Quoi qu'il en soit, à la fois en ouvrant une nouvelle fenêtre et en devant démarrer un nouvel onglet à l'intérieur de celle-ci, ce n'est pas plus facile que d'exécuter un processus élevé à partir de mon menu Démarrer. Ce que j'ai décrit dans ma réponse initiale fournit le comportement exact que j'imaginais.

@ayfine - et j'ai copié votre exemple gsudo. C'est une solution suffisante jusqu'à ce que quelque chose d'intégré soit codé. Merci.

@ayfine J'ai essayé le gsudo, mais c'est une expérience assez horrible. Tout type de complétion TAB semble se casser et les caractères Unicode (non-ASCII) ne semblent pas s'afficher. Je suppose que c'est une sorte de processus qui redirige les entrées et les sorties, et qui fait un travail terrible. Je pense que la solution avec une fenêtre séparée fonctionne mieux.

Si vous rencontrez des problèmes avec gsudo, veuillez les signaler à @gerardog et non dans ce fil. Chaque message sur ce fil (celui-ci inclus ; désolé !) envoie des e-mails à des centaines d'abonnés.

Je vais verrouiller ce fil √† d'autres commentaires non responsables, car nous atteignons le point o√Ļ d'autres commentaires ne font pas avancer la discussion de mani√®re significative.

Veuillez signaler de nouveaux problèmes si vous avez des préoccupations qui ne sont pas couvertes ici.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

NickITGuy picture NickITGuy  ¬∑  3Commentaires

waf picture waf  ¬∑  3Commentaires

mrmlnc picture mrmlnc  ¬∑  3Commentaires

dev-logan picture dev-logan  ¬∑  3Commentaires

miniksa picture miniksa  ¬∑  3Commentaires