Terminal: [質問]常に昇格して起動するようにWindowsターミナルプロファイルを構成する

存在しない。 少しセキュリティホールであるため、高架タブと非高架タブの混合をサポートする予定はないと思います。

はい、私はsudoが問題であることを知っていますが、Windows用のsudoの作成について、セキュリティチームと多くの議論を重ねてきました。 主な問題は、昇格されていないプロセスが他の昇格されていないウィンドウにキーストロークを送信する可能性があるという事実によるものです。

昇格されたコマンドラインが昇格されていないウィンドウで実行されている場合、信頼できない悪意のある攻撃者が、昇格されたコマンドラインを実行している昇格されていないウィンドウを駆動することにより、特権の昇格攻撃を実行する可能性があります。

（関連するスレッドのリンクに関しては、＃146）

編集（2020年2月14日）
さて、このコメントはあまり古くなりませんでした。 もともと、これをサポートする計画はありませんでした。これは、私たちが持っていた単一のHWNDでは機能しないためです。 将来的にはこれをサポートする可能性のあるソリューションの設計に取り組んでいますが、適切に安全なソリューションを考え出すことができると確信するまで、何も約束できません。これにより、特権の低いプロセスでは不可能になります。より高い特権の端末を駆動します。

合理的なようです。 ＃576（ジャンプリストで管理者として開く）の組み合わせのようなものと、ターミナルの管理者セッションを起動するための何らかのホットキーがあれば、ここでの私の苦痛のほとんどを解決できると思います。

標準の高架ターミナルを単一のウィンドウで開いているが、タブを分けているのはどうですか？

@mdtauk残念ながら、同じカテゴリに分類されると思います。 すべてのタブが同じHWNDの下にあるため、ルートHWNDは、昇格されていないアプリがウィンドウを駆動するのを防ぐために昇格する必要があるものです。

セキュリティの観点から（Windows Terminalの設計、シングルルートHWNDなどを無視）、現在のUXで1つの昇格されたPowerShellインスタンスの隣に1つの昇格されたPowerShellインスタンスを実行する場合と比較して、ターミナルが混合標高タブを実行することの「安全性が低い」 ？ コンソールアプリがターミナルタブでホストされているという事実は、私には違いがありません...

同様の注意事項：リモートPSセッションを開いた場合でも、昇格されていないウィンドウをより安全にするには、昇格されていないウィンドウが駆動できるリモートサーバーの管理者権限を持っている可能性があります。 私にとって、これはローカル管理者アクセスを取得するよりもはるかに悪いように思われるので、管理者としてタブを実行することは、他のサーバーにリモート接続/ SSH接続することと何ら変わりはないと思います。 どちらの場合も、システムを快適に使用できるようにする必要があります。 それは「私は十分に年をとっていて、リスクを理解している」ということです。

管理者アカウントでターミナルアプリを実行しようとすると、右クリック->管理者として実行すると、UACが2回ポップアップし、次のようなエラーが発生します。
「Windowsが（path \ WindowsTerminal.exe）を見つけることができません。入力したことを確認してください...」。

パスは存在し、アプリはアプリを作成した非管理者ユーザーに対して正しく機能しますが、他の管理者ユーザーはそれを実行できません。
管理者ユーザーにログインすると、ターミナルアプリは、システムにインストールされていないかのように、設定にもスタートメニューにも表示されません。

すべてのユーザーにインストールされるようにアプリを構築する方法はありますか？ または、プロジェクトのルートはユーザー固有ではないディレクトリにある必要がありますか？

@

管理者アカウントでターミナルアプリを実行しようとすると、右クリック->管理者として実行すると、UACが2回ポップアップし、次のようなエラーが発生します。
「Windowsが（path \ WindowsTerminal.exe）を見つけることができません。入力したことを確認してください...」。

パスは存在し、アプリはアプリを作成した非管理者ユーザーに対して正しく機能しますが、他の管理者ユーザーはそれを実行できません。
管理者ユーザーにログインすると、ターミナルアプリは、システムにインストールされていないかのように、設定にもスタートメニューにも表示されません。

すべてのユーザーにインストールされるようにアプリを構築する方法はありますか？ または、プロジェクトのルートはユーザー固有ではないディレクトリにある必要がありますか？

同じ問題が発生しているのを見ています。

Windowsバージョン18922.1000

そうです、管理者または別のユーザーとしてストアアプリを実行することは機能していません（設計上）。 私たちの多くは、通常の昇格されていないアカウントとして（PCに）ログインしています。 管理者としてpowershell / cmd / etcを実行して、特定のタスクを実行します。

このアプリを展開することが最終的な選択である場合、Windowsストアである場合、昇格されたタブを開く方法がないと、私には役に立ちません。 私の2セント。

「役に立たない」というのは少し厳しいかもしれませんが、実際には、昇格されていないコンソールアプリと昇格されたコンソールアプリ/シェルの両方に新しい端末を使用する方法が必要です。 そして、私にとって最高のUXは、同じWindowsターミナルインスタンスで昇格されたタブと昇格されていないタブの組み合わせをサポートすることです。 あまり好ましくない：0から多数（通常は1つ）の非昇格インスタンス（通常は1つから多数のタブ）と0から多数（通常は1つ）の非昇格インスタンスをサポートします。

ConEmuは、同じウィンドウで高架タブと非高架タブを混在させることができます。 そのようなことはここではできませんか？

高架ターミナルの起動非高架タブを使用できますか？ 昇格したタブを起動する必要がありますが、「保護」された新しいタブを開くことができます。

非常にWindows固有に移行し、最終的にターミナルが表示される可能性のある他のプラットフォームを無視したい場合は、Windowsコンテナまたは仮想化プロセスを使用すると、この問題点に役立つ可能性があります。 私は個人的には現在のソリューションで問題ありませんが、コンソールアプリをデフォルトで分離されたプロセスとして実行することは、セキュリティの観点からは悪い考えではありません。

少なくとも私にとっては、1つのウィンドウでの混合高度は必須です。
設定で切り替えるオプション機能でしょうか？

@pratnala ConEmuを使用すると、それが実行されているように見えるだけですが、実際にはまったく実行されていません。 昇格された「タブ」と昇格されていない「タブ」は、2つの完全に分離された独立したルートウィンドウ/プロセスへの単なるビューです。 これは、特にウィンドウのコンテンツやプロキシ/ブローカーの昇格ヘルパーなどをスクレイピングすることによって行われます。 確かに、それは技術的には可能ですが、ConEmuが行うことは実際にはちょっと危険です。 サードパーティのプログラムがこれを実行し、ConEmuをダウンロードしてリスクを選択させることは1つのことですが、Microsoftがこれを自分で行うことでこれを公式に承認することはまったく別のことです。 玄関の鍵を玄関マットの下に隠したいのなら、それなら大丈夫です。それは私のばかげたリスクです。 しかし、購入したすべてのドアが玄関マットの下に鍵のセットを置いた場合はどうなるでしょうか。

しかし、ほら、私はC ++（そして、C＃、PowerShell、Ruby、Python、GoLang、私の道に来るほとんどすべてのもの）で開発しています。私は、mingwとともにConEmuとTakeCommandをインストールしています。 走っている間、はさみをどのように保持するかを知っています。

PowerShellはセキュリティホールです。 あらゆる種類の予期しないアクセスを可能にする非常に便利な自動化ツール。 そして、私たちが求めているもの（混合モード）は、代替手段（すべて高架）よりも確かに安全です。実際、この（ターミナル）はパワーユーザー向けの動力工具であり、そのほとんどはおそらくセキュリティの状況を非常によく理解しています...そして理解しています実用的な妥協。

ゼロトラストは、衰弱していない場合にのみ機能します。

@robomacはさみを正しい方法で持ち、一緒に走らない方法を知っている人だけがこのプロジェクトを_使用_するだろうとセキュリティチーム（混合標高の近くに遠く離れて冒険することさえしないように何度も私たちに言った）を説得できれば、私たちはおそらくそれをするでしょう。 自分で信じているかどうかわかりません。 理由は次のとおりです。

そうでない場合と同様に、ターミナルが混合高度で実行されている場合（Medium-ILホストからHigh-ILクライアントへ）、そのユーザーとして実行されている他のユーザーからの入力を強制的に受信することができます。 キーボードの後ろにいる人が聖人であり、昇格する必要がある10秒間だけ昇格する場合でも、_彼女のユーザーアカウントで実行されているアプリケーションは、追加の昇格プロンプトなしで管理者になりすますことができます_。 完全に検出されていない可能性があります。

@ DHowett-MSFTご返信いただきありがとうございます。 とにかく悪意のあるプロセスの実行を許可していると想定します。 毎朝下向きの犬のポーズで行う「ベストプラクティス」のマントラから許可を制限しますが、ターミナルへのアクセスが数時間であっても、自分のシステムで危険にさらされることが本当に心配な場合は、あなたは上で開発しています_..。

1. ターミナルを実行してはいけません
2. ワイプして最初からやり直す必要があります。

（コンピューターの）ウイルス研究者がベクターパスでこれを危険にさらすべきではないことを認めます...しかし、早い段階でさえ、VMでそれらをサンドボックス化していました。 しかし、「ターミナル」はあなたの知識のない親戚のためのものではありません。 それは動力工具です。

リスクに対処するための標準的な方法があります。 ブラウザの世界からお届けします。 高度なフラグに移動すると、大まかに「ここにドラゴンがいます」という警告が表示されます。 （これは、深刻なハードコアセキュリティブラウザであるPale Moonの場合とまったく同じだと思います。）（非UAC、追加の）警告を追加しますが、ユーザーに決定させます。

もう1つの質問：ターミナルの2つの異なるセッション（1つは昇格、もう1つは昇格しない）は期待どおりに動作しますか？ それとも、両方が任意のセッションのベクトルになりますか？

私は人々がこのようなものにオプトインできるべきであることに同意しません。 ：笑顔：

2つの異なるセッション

ああ、ええ、それは今日絶対に機能するはずです-ベクトルではありません（高架のものは世界の高IL側で完全に実行されており、他の中ILプロセスによって駆動することはできません）

それは今日絶対に機能するはずです

同じ精神で、2つのタブを異なるプロセスで実行して、同じウィンドウで混合標高を有効にすることはできませんか？

@ DHowett-MSFTでは、なぜ2つの異なるセッションを包括的なアプリでホストできないのでしょうか。 本当に難しいことではありません。

そもそも昇格されたコンソールアプリを使用することのセキュリティへの影響は理解していると思いますが、Windowsターミナル内に2種類のタブ（昇格と非昇格）があると、Windowsがサポートしているものよりも_リスクが高くなる_理由がわかりません。何年にもわたって、つまり、昇格されたCMDと昇格されていないCMD / PowerShellを並べて実行します。 誰かがこれに光を当てることができますか？

@robomac
[1]従来のウィンドウハンドルを使用して_従来のウィンドウをホストする_場合は簡単です。 これは、conemuの場合、または昇格されたセッションでウィンドウを引き継ぎ、昇格されていないセッションでウィンドウの下に親を再設定できるタブ付きシェルの場合に非常にうまく機能します。

その際、[2]で触れるセキュリティ機能がいくつかあります。 そのため、親にすることはできますが、実際に何かを強制することはできません。

ただし、問題があります。 ターミナルは、親を変更可能なウィンドウのコレクションとして設計されていません。 たとえば、コンソールホストを実行しておらず、ウィンドウをタブに移動していません。 これは、テキストの読み取りと書き込みが可能な「接続」をサポートするように設計されています。 これは、ウィンドウよりも低レベルのプリミティブです。 私たちは自分たちのやり方の誤りに気づき、UNIXモデルは常に正しいと判断し、パイプ、テキスト、ストリームは_現在の場所にあります。_

Xamlアイランドを使用して最新のUIをホストし、それにDirectXサーフェスをステッチしていることを考えると、とにかく標準のウィンドウハンドルの世界をはるかに超えています。 Xamlアイランドは、ChromeやFirefox、およびDirectX / OpenGL / SDLゲームの全範囲と同様に、単一のHWNDに完全に構​​成されています。 前述の「接続」ではない、あるプロセスで実行（昇格）し、別のプロセス（昇格しない）でホストできるコンポーネントはありません。

さて、明らかなフォローアップの質問は、_「なぜあなたは非高架接続の隣のタブに1つの高架接続を持つことができないのですか？」_これは@ sba923が読みを拾うべき場所です（：smile :)。 あなた（@robomac）がすでに知っていることをいくつか取り上げるつもりです。

[2]同じウィンドウステーションの同じデスクトップに2つのウィンドウがある場合、それらは相互に通信できます。 SendKeysからWScript.Shellまで簡単に使用して、シェルが表示できる任意のウィンドウにキーボード入力を送信できます。

プロセスを実行すると、その接続が_切断_されます。 シェルは高架ウィンドウを見ることができません。 シェルと同じ整合性レベルの他のプログラムは、昇格されたウィンドウを見ることができません。 ウィンドウハンドルが付いていても、実際には操作できません。 これは、メモ帳が高架で実行されている場合、エクスプローラーからメモ帳にドラッグアンドドロップできない理由でもあります。 別の昇格されたプロセスのみが、別の昇格されたウィンドウと対話できます。

その「セキュリティ」機能（好きなように呼んでください。おそらく、ある時点でセキュリティ機能になることを目的としていました）は、いくつかのセッショングローバルオブジェクトタイプにのみ存在します。 Windowsはその1つです。 パイプは実際にはそれらの1つではありません。

そのため、そのセキュリティを破ることは簡単です。 その例としてターミナルを取り上げます。 高架接続を開始し、それを_非高架_ウィンドウでホストすると、そのセキュリティ境界を通るコンジットが突然作成されます。 もう一方の端にある高架式のものはウィンドウではなく、単なるテキストモードアプリケーションです。 昇格されていないホストの入札をすぐに行います。

標高のないホスト（ WScript.Shell::SendKeysなど）を_制御_できる人は誰でも、標高の境界を通過するインスタントコンジットを取得します。 突然、システム上の中程度の整合性アプリケーションが高整合性プロセスを制御できるようになります。 これは、ブラウザ、NPMのleft-padパッケージとともにインストールされたビットコインマイナー、または実際にはさまざまなものである可能性があります。

小さなリスクですが、リスクです。

他のプラットフォームは、ユーザーの利便性を優先してそのリスクを受け入れています。 そうすることは間違いではありませんが、Microsoftは、「ユーザーの利便性のためにリスクを受け入れる」などの「合格」を得ることが少ないと思います。 Windows 9xは軽減されていないセキュリティ災害であり、制限されたユーザーアカウントと昇格プロンプト、およびウィンドウ管理用のカーネルレベルのセキュリティがそれらの答えでした。 軽く緩めるためのロックではありません。

@ DHowett-MSFT説明していただきありがとうございます。 最近のコンソールアプリで行っているように、Windowsターミナルの1つの昇格されたインスタンスと1つの昇格されていないインスタンスを並べて実行することに慣れる必要があると思います。

魅力的な。 ありがとう。 ターミナルは、ウィンドウよりも接続レンダラーであることが理にかなっています。 これにより、PowerShellは、すでにパイプ/接続に重点を置いており、ウィンドウ化されたコンソールで以前に制御できるようになりますか？

別々のターミナルセッションは互いに完全に分離されていますか？

昇格したセッションにいることを示すだけで、完全に満足します。 「管理者：\ 私は今のところかなり悪いことを見逃しています。

???

「別のユーザーとして実行」は、すべてのWindows管理者が必要とするものです。 利用可能な場合、これは非常に役立ちます。 最良のオプションは、各プロファイルの構成にフラグを設定することです。

ところで、ウィンドウの分離について言えば、最新のctfmon脆弱性レポートを引用させてください

明らかな攻撃は、特権のないユーザーが管理者のコンソールセッションにコマンドを挿入したり、ユーザーがログインしたときにパスワードを読み取ったりすることです。サンドボックス化されたAppContainerプロセスでも同じ攻撃を実行できます。

@eckiそれはかなり気がかりなニュースです。 その後、テイビスは今夜パーティーをやめていると思います。

@ DHDHowett-MSFT
ここに多くの人が書いているように、新しい端末が多数のユーザーよりも「別のユーザーとして実行」オプションで開始できない場合、それはあまり使用できず、Microsoftの「ActiveDirectory管理層モデル」とも互換性がありませんたとえば、デフォルトの権限を持つADユーザーがいて、ドメインコントローラーでAdminuserを使用してPSスクリプトを実行している場合。

現在ログインしているユーザーで端末を起動することはあまりありませんが、この端末の使用例は何ですか？ ping、nslookupなど。それが意図である場合、なぜこれほど多くの作業を行うのですか？

「管理者として実行」を使用すると、いくつかの有効なポイントがありますが、（PS6 / 7）のような他のコンソールが安全でない場合でも、これらの機能をサポートしているのはなぜですか？

新しいターミナルアプリは、すべての個別のcmd / PS /…ウィンドウに取って代わるといつも思っていましたが、実際の多くのシナリオでは使用できないようです。 これはちょっと悲しいtbhです...

@Fisicoあなたの経験は普遍的ではありません。誰かに彼らのプロジェクトの存在そのものを正当化するように頼むとき、それを考慮することをお勧めします。

「別のユーザーとして実行」が存在しない/機能していないという包括的なポイントに、これは私たちが解除しようとしているプラ​​ットフォームの制限です。 私たちがそれをサポートしないのは、悪意や無能によるものではありません。

他のコンソールアプリケーションがサポートしている理由については、同じウィンドウで異なる高度レベルをホストしていないため、サポートしている場合でも安全ではありません。 それがここでの中心的な問題です。 これらはスタンドアロンウィンドウを備えたスタンドアロンプ​​ロセスでホストされるため、クロスインテグリティレベルの操作に関する制限がありません。

@ DHowett-MSFT
申し訳ありませんが、私の投稿であなたを怒らせた場合、それは私の意図ではありませんでした、私はそれにあまりにも多くの感情を入れました。
ターミナルは素晴らしいアイデアであり、非常に大きな可能性を秘めていると思います。コミュニティと一緒にターミナルを開発して、ターミナルを最大限に活用していただき、ありがとうございます。

この時点で、何が実装され、何が実装されていないかについて、非常に多くの混乱があります。
現在、アプリ全体の「管理者として実行」が機能していますが、これは今後も続くのでしょうか。

私が理解しているように、各タブ/プロファイルの「管理者として実行」は実装したいものではありません。 これは私たちのほとんどにとって大丈夫だと思います。

「別のユーザーとして実行」は、Windowsがアプリでサポートしていないため不可能であり、Windowsがサポートするまで待つ必要がありますか？ もしそうなら、私たちは何年も話しているのですか？

タブ/プロファイルごとの「別のユーザーとして実行」も実装したくないものですか？

@ DHDHowett-MSFT
ここに多くの人が書いているように、新しい端末が「別のユーザーとして実行する」オプションで開始できない場合
多くのユーザーにとって、それはあまり使い勝手が良くありません...私はいつも新しいターミナルアプリが
個別のcmd / PS /…ウィンドウをすべて置き換えますが、実際の多くのシナリオでは使用できないようです。 これはちょっと悲しいtbhです...

同意しません。 これは私たちが以前持っていたものよりも大きな進歩です。 残念ながら、私たちのほとんどは、よりきめ細かいアプローチがないために、シェルを高くして実行する習慣を身に付けている可能性があります...そしてそれでも可能です。 それらを_ミックス_することはできません...しかし、私たちは決してしませんでした。 真剣に、私が行った_最後の3つの_会社では、DeveloperWikiはすべてのビルド/テストを昇格されたVSプロンプトで実行しています。 リアルタイムスキャン、積極的なアクティブファイアウォール、および開発者がめったに失敗しないことを認識して、セキュリティを実装します。 _non-developers_は、（1）信頼できないため、（2）信頼する必要がないため、昇格することはありません。

ですから、私はこの新しいターミナルに感謝しています。 完璧ではありませんが、Take Command / TCCでもありません。 少なくともこれは標準です。

@ DHDHowett-MSFT
ここに多くの人が書いているように、新しい端末が「別のユーザーとして実行する」オプションで開始できない場合
多くのユーザーにとって、それはあまり使い勝手が良くありません...私はいつも新しいターミナルアプリが
個別のcmd / PS /…ウィンドウをすべて置き換えますが、実際の多くのシナリオでは使用できないようです。 これはちょっと悲しいtbhです...

同意しません。 これは私たちが以前持っていたものよりも大きな進歩です。 残念ながら、私たちのほとんどは、よりきめ細かいアプローチがないために、シェルを高くして実行する習慣を身に付けている可能性があります...そしてそれでも可能です。 それらを_ミックス_することはできません...しかし、私たちは決してしませんでした。 真剣に、私が行った_最後の3つの_会社では、DeveloperWikiはすべてのビルド/テストを昇格されたVSプロンプトで実行しています。 リアルタイムスキャン、積極的なアクティブファイアウォール、および開発者がめったに失敗しないことを認識して、セキュリティを実装します。 _non-developers_は、（1）信頼できないため、（2）信頼する必要がないため、昇格することはありません。

ですから、私はこの新しいターミナルに感謝しています。 完璧ではありませんが、Take Command / TCCでもありません。 少なくともこれは標準です。

昇格！=別のユーザーとして実行します。
私はPowerShellを他のADユーザーで実行し、次に自分のADユーザーで実行します。
必要がない場合でも、管理者としてcmdまたはPSを実行することがよくありますが、管理者として実行しなければならない場合が非常に多くあります。 ほとんどのsysadminタスクには、管理者権限またはある種の権限を持つ別のユーザーが必要です。
確かに、ユーザーコンテキストでcmdを実行する必要がある場合は、すべて問題ありません。

「昇格！=別のユーザーとして実行する」ことを理解しています。 「別のユーザーとして実行する」というのは、あなたが主張するほど一般的ではないと私は信じています。

「昇格！=別のユーザーとして実行する」ことを理解しています。 「別のユーザーとして実行する」というのは、あなたが主張するほど一般的ではないと私は信じています。

あなたが絶対にそれを必要とするよりもあなたがマイクロソフトの世界と関係があるなら。
たとえば、ドメイン管理者権限を持つWindowsマシンにログインすることは最善の方法ではありません。
domainadmin権限またはその他の権限を持つユーザーでPSスクリプトを実行することは非常に一般的です。

@Fisicoでは、 New-PSSessionコマンドを使用してみませんか？

サービスに特定の種類の昇格を必要とする自動スクリプトでは、通常、「別のユーザーとして実行」する必要があります。 それがターミナルに当てはまるかどうかは別の話です。 runasコマンドを使用すると、CMDまたはPSセッションでいつでもログインを変更できます。 これは、通常のユーザーである基礎となるログインを利用しているため、タブの標高状態を変更しません。 また、タスクスケジューラまたはcronジョブを使用して実行するスクリプトは、通常のコンソールセッションには存在しない機能を取得するためにターミナルを利用しない限り、ターミナルを実行する必要はありません。 その場合は、バックグラウンドプロセスとして起動するターミナルでそのスクリプトを実行するためのパラメータを利用することが解決策になります。

したがって、タブの高さを混在させる必要はありません。 回避策があり、必要な特定のrunasコマンドをtxtファイルにコピーして、ターミナルにコピーして貼り付けてからパスワードを入力するのは簡単です（暗号化されていないものにパスワードを保存しないでください）。

@SamuelEnglard
スクリプトを実行するために、リモートホストに接続したくありません。

@WSLUserはい、runasを使用するオプションですが、ターミナルまたはPSを別のユーザーとして実行する方がはるかに便利です。 なぜこれが問題になるのかわかりません。

@Fisico New-PSSessionは、リモートコンピュータに接続する必要はありません。最初の2番目の構文エントリを参照してください。

@SamuelEnglard
スクリプトを実行するために、リモートホストに接続したくありません。

@WSLUserはい、runasを使用するオプションですが、ターミナルまたはPSを別のユーザーとして実行する方がはるかに便利です。 なぜこれが問題になるのかわかりません。

ユーザーがPowerShellをタスクバーに固定し、右クリックして管理者として実行するか、一部の環境ではRunAs OtherUserを実行するには昇格したアカウントが必要であるため、エンタープライズレベルのスクリプトを実行するのはかなり標準的な操作です。 ターミナルで不可能と言うのは、PSLockDownを活用し、RunAsAdminにシェルまたはVSCodeをロードするように強制する環境のようなものです。
私見では

本当に別のユーザーとしてタブを実行する必要がある場合は、開始時にNew-PSSession -Credential | Enter-PSSessionを実行するプロファイルを作成できます。

免責事項：私はこれを行うことによって台無しにされたコンピュータに対して責任を負いません。

本当に別のユーザーとしてタブを実行する必要がある場合は、開始時にNew-PSSession -Credential | Enter-PSSessionを実行するプロファイルを作成できます。

>免責事項：私はこれを行うことによって台無しにされたコンピュータに対して責任を負いません。

確かに、またはここに立っている「セキュリティ」は再考される可能性があります。 ここでも、PowerShellをタスクバーに固定します。そこから、昇格されていないPowerShellを起動できます。 それを右クリックして[管理者として実行]を選択します。企業環境でアイコンを右クリックしてから、Shiftキーを押しながら右クリックして[Windows PowerShell]を選択し、[別のユーザーとして実行]を選択してPowerShellを起動します。代替の資格情報を使用します。 セッションはなく、これらの資格情報を取得するために別のホストにRDPを実行することもありません。

確かに、またはここに立っている「セキュリティ」は再考される可能性があります。 ここでも、PowerShellをタスクバーに固定します。そこから、昇格されていないPowerShellを起動できます。 それを右クリックして[管理者として実行]を選択します。企業環境でアイコンを右クリックしてから、Shiftキーを押しながら右クリックして[Windows PowerShell]を選択し、[別のユーザーとして実行]を選択してPowerShellを起動します。代替の資格情報を使用します。 セッションはなく、これらの資格情報を取得するために別のホストにRDPを実行することもありません。

はい、Windowsターミナルでも同じことができます。 同意しました。 異なるユーザー（または異なる標高）として実行されているタブを組み合わせたい場合に、それがどのように役立つかわかりません。

「混合タブ」はさておき、明確にしておきたいのですが、Windowsストアアプリの設計により、（リリースされたプレビューの）Windowsターミナルではそれを行うことはできません。 そのアプリをインストールし、同じユーザーとしてログインしたユーザーとしてのみ実行できます。

私が望んでいるのは、今日私がしていることを実行し、通常のユーザーとしてPCにログオンし、昇格したシェルを実行できるようにすることです。 Windows Terminalがそのままリリースされたとしても、私にはほとんど役に立たない。

とても良い点です。 この制限は、Windowsターミナルのプライベート（ストア以外の）ビルドには存在しません。

「混合タブ」はさておき、明確にしておきたいのですが、Windowsストアアプリの設計により、（リリースされたプレビューの）Windowsターミナルではそれを行うことはできません。 そのアプリをインストールし、同じユーザーとしてログインしたユーザーとしてのみ実行できます。

私が望んでいるのは、今日私がしていることを実行し、通常のユーザーとしてPCにログオンし、昇格したシェルを実行できるようにすることです。 Windows Terminalがそのままリリースされたとしても、私にはほとんど役に立たない。

Windowsターミナルのストアビルドの2つのインスタンスを開いたところです。1つは昇格し、もう1つは昇格していません。 だから私はそれがあなたのために働いていない理由がわかりません。

わかりました。あなたはPCのローカル管理者であると信じなければなりません。 明確にするために、多分私は明確にする必要があります。 私は自分のワークステーションのローカル管理者ではありません。 したがって、「管理者として実行」に移動すると、ユーザー/パスワードの入力を求められます。

私が使用する「admin」アカウントは、通常のマルウェア/メール読み取りアカウントとは異なります。 したがって、技術的には、私が行うことは別のユーザーとして実行されます。 これは、Windowsストアアプリの制限です。 解決策（そしておそらく彼らはこれを行うでしょう）は、これらの制限がないWindowsコンポーネントとしてこれをリリースすることです。

* [緊急]この問題の解決策を見つけました！ ** _

このガイドに従うことによって
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
あなたはWindowsアプリフォルダをあなた自身のものにすることができます！

これを実行すると、 Microsoft.WindowsTerminal._blahblahYourVersion_フォルダーを見つけることができます。 中に入ると、以下に示すWindowsTerminal.exeを見つけます

見つけたら、このファイルのショートカットを作成して、好きな場所に配置します。 その後、管理者として実行するように設定します。 これを行うには、右クリックして[プロパティ]> [詳細設定]> [管理者として実行]に移動します。その後、[OK]をクリックすると、すべて設定されます。

個人的には、タスクバーのショートカットを使用して_Windows + 1_を押すだけで管理者として起動できるため、これが必要でした。 スタートメニューを正しく実行するためにナビゲートするのに長い道のりではありません。

リリースページに置いたバンドルを解凍することもできます。 単なるZIPファイルです。 パッケージ化されていない実行は_公式にはサポートされていません_。

しかし、これはまだ昇格して実行するための_サポートされた_方法がないことを意味します！ これは必須の機能だと思います。

確かに、私は正直に立っています。

欠落しているのは、タスクバーのショートカットの右クリックメニューにある「管理者として実行」エントリです。

昨日のミートアップで数人と話をしましたが、数人は主にWindows + XでPowerShellを起動し、そこで管理者としてターミナル/ターミナルを持ちたいと言っていました。

とても良い点です！

それがまさに私のポイントです！ これは、タスクバーから実行するためのソリューションです
管理者権限で！

2019年8月25日、日曜日、午前1時8分Sté[email protected]
書きました：

とても良い点です！

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWS
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
。

確かに、私は正直に立っています。

欠落しているのは、タスクバーのショートカットの右クリックメニューにある「管理者として実行」エントリです。

タスクバーで2回右クリックします。 アイコンを表示してコンテキストメニューを表示し、次にアプリ名を表示します。 例：「Windowsターミナル（プレビュー）」を選択し、「管理者として実行」を選択します

戸惑いました。

顔を赤らめる。

恥ずかしかった。

どうして私はこれを考えなかったのですか？

とにかく私たち全員と共有してくれてありがとう！

もう一方の端から問題を見てみましょう...
Windowsでは、昇格されていないプロセスが他の昇格されていないプロセスを制御したり、キーストロークを送信したり、UIをキャプチャしたりできますが、昇格されていないプロセスが昇格されたプロセスのウィンドウに対してそれを実行することはできません。
Windowsターミナルは、ssh、PowerShellリモーティングなどを介してリモートサーバーを管理するためにも使用されるように設計されています...
これは、ローカルマルウェアがWindowsターミナルセッションがユーザーの行動をスパイするのを待つ可能性があるため、Windowsターミナルが管理に使用されるとすぐにセキュリティホールになり、リモートシェルを検出したらすぐに次のことを試みます。管理者権限を使用してサーバーに感染するコマンドを挿入します。

Windowsターミナルを管理者として実行しないようにすることは、セキュリティの向上にはまったく見えません。管理者として実行すると、代わりに、昇格されていないプロセスがリモートシェルセッションを乗っ取るのを防ぐことができます。 ユーザーがローカルまたはリモートで昇格したコマンドプロンプトを表示するツールを使用する場合は常に、管理者として実行することをお勧めします。

また、sudo for Windowsについては、sshdサービスを実行してから、昇格されていないシェルからlocalhostに接続すると、同じセキュリティの問題が発生しませんか？

これは、ローカルマルウェアがWindowsターミナルセッションがユーザーの行動をスパイするのを待つ可能性があるため、Windowsターミナルが管理に使用されるとすぐにセキュリティホールになり、リモートシェルを検出したらすぐに次のことを試みます。管理者権限を使用してサーバーに感染するコマンドを挿入します。

リモートシステムが感染する可能性があることは事実ですが（リモートプロセスに管理者権限があると仮定）、ローカルシステムにも感染させる必要があるという意味ではありません。

Windowsターミナルを管理者として実行しないようにすることは、セキュリティの向上にはまったく見えません。管理者として実行すると、代わりに、昇格されていないプロセスがリモートシェルセッションを乗っ取るのを防ぐことができます。 ユーザーがローカルまたはリモートで昇格したコマンドプロンプトを表示するツールを使用する場合は常に、管理者として実行することをお勧めします。

現在、管理者権限でWindowsターミナルを実行することを妨げるものは何もありません。 当面の問題は、高架タブと非高架タブが混在していることです。

@SamuelEnglardが応答にスポットを当てます。

さらに、私たちがやろうとしているのは、_new_セキュリティホールの追加を避けることです。 元のコンソールは、リモートサーバー管理と同じ問題でした。 残念ながら、それについて私たちにできることは何もありません。 リモートサーバー管理を行うユーザーは、常にコンソール/端末を昇格させて実行しているため、セキュリティが強化されます（ただし、私はセキュリティの専門家ではないため、そのステートメントをアドバイスとは見なしません）。

この問題の進捗状況のアイデア：_app_全体を昇格として実行してみてください。それが成功した場合は、UACシールドのアイコンが付いた各「開く」ボタンの横にボタンを追加し、昇格したタブを開くためのプレフィックスキーバインドを追加します。 Ctrl ShiftE 。 （チェックしたところ、これはバインドされていませんでした。）次のタブを開いたときにのみ機能します。

とにかく、開いたタブには通常のアイコンの前にUACアイコンがあり、管理者として実行されます。 （プログラムはこのキーを送信できなくなりました。管理者としてアプリを実行しました。）

アプリは自動昇格を試み、それが失敗した場合は正常に実行し、このスレッド全体を無視する必要があります。

確かに、私は正直に立っています。
欠落しているのは、タスクバーのショートカットの右クリックメニューにある「管理者として実行」エントリです。

タスクバーで2回右クリックします。 アイコンを表示してコンテキストメニューを表示し、次にアプリ名を表示します。 例：「Windowsターミナル（プレビュー）」を選択し、「管理者として実行」を選択します

その場合に表示されるUACプロンプトに、「不明なプログラム」と表示されていることに気づきました。

あなたが私に尋ねるなら、むしろ予想外です...

@ sba923それは＃2289：smile：

@ DHowett-情報をありがとうMSFT; それが（すでに）追跡されていることを知っておくとよいでしょう。

私が考えることができるこれに対する最良の答えは、プロファイルを昇格させる必要があるオプションを用意することです。現在のウィンドウが昇格されていない場合は、そのプロファイルで新しい昇格されたインスタンスを開始します。 （プライベートブラウジングセッションがどのように機能するかを考えてください）

非常に良いアイデア

この方法を使用して、Win + Xメニューにターミナルを追加しました。
ターゲットを使用して新しいショートカットを作成します。
C：\ Windows \ explorer.exe shell：appsFolder \ Microsoft.WindowsTerminal_xxxxxxxxxxxx！App
編集：
申し訳ありませんが、アプリを管理者として実行する場合、これは機能しません。
代わりに、nircmdを使用して、でショートカットを作成できます。
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

（「Microsoft.WindowsTerminal_xxxxxxxxxxxx」の正しいパスは、PSコマンド「Get-appxpackage * WindowsTerminal *」で確認できます。PackageFamilyNameのエントリを使用してください）

このショートカットを使用すると、ダブルクリックするだけで管理者権限でターミナルを起動でき、WinXEditorを使用してWin + Xメニューに追加できます。
注：端末は、管理者アカウントにもインストールされている必要があります。

すべてのプロファイルを管理者としてロードするのですか、それとも特定のプロファイルのみをロードするのですか？ 理想的には、個人のプロフィールでそれを持っていたいです。 たぶん、「ルーン」アカウントであり、「昇格」された別のプロパティであるプロパティですか？

このスレッドで詳細に説明されているように、Windowsターミナルの同じインスタンスで昇格と非昇格を混在させることはできません。これは追加されません。

確かに、私は正直に立っています。
欠落しているのは、タスクバーのショートカットの右クリックメニューにある「管理者として実行」エントリです。

タスクバーで2回右クリックします。 アイコンを表示してコンテキストメニューを表示し、次にアプリ名を表示します。 例：「Windowsターミナル（プレビュー）」を選択し、「管理者として実行」を選択します

FWIW、Shiftキーを押しながら右クリックすると、[管理者として実行]オプションがすぐに表示されます。これは、以前に行っていた2回の右クリックオプションよりもわずかに高速です。

やあみんなUACを忘れましたか？ アプリケーションは安全なデスクトップで物をクリックすることはできません。

FWIW、Shiftキーを押しながら右クリックすると、[管理者として実行]オプションがすぐに表示されます。これは、以前に行っていた2回の右クリックオプションよりもわずかに高速です。

また、Ctrlキーを押しながらShiftキーを押しながらアイコンを左クリックして、UACを即座に表示することもできます。

素晴らしい、たくさんありがとう！ 覚えておく必要のあるショートカットはいくつありますか？ ;-)

「別のユーザーとして実行」が存在しない/機能していないという包括的なポイントに、これは私たちが解除しようとしているプラ​​ットフォームの制限です。 私たちがそれをサポートしないのは、悪意や無能によるものではありません。

他のコンソールアプリケーションがサポートしている理由については、同じウィンドウで異なる高度レベルをホストしていないため、サポートしている場合でも安全ではありません。 それがここでの中心的な問題です。 これらはスタンドアロンウィンドウを備えたスタンドアロンプ​​ロセスでホストされるため、クロスインテグリティレベルの操作に関する制限がありません。

別のユーザーとして実行することは、ある時点でやってくるものであることを間違いなく望んでいます。 私の日常の活動の大部分ではありませんが、一部のPowerShellコマンドレットでは昇格が必要です（さまざまなユーザーで実行しているので、保護されたユーザー管理者だと思います）。

それは世界の終わりではありませんが、レガシーシェルに戻らなければならないことは確かに迷惑です。

やがて、私は推測します！

昇格されたWindowsターミナルの使用にはまったく問題/制限がないため、「レガシーシェル」（より正確には、レガシーコンソールホスト）に固執する必要はありません。

同じインスタンス（内部の異なるタブ）で高架と非高架を混在させることはできません。

昇格されたWindowsターミナルの使用にはまったく問題/制限がないため、「レガシーシェル」（より正確には、レガシーコンソールホスト）に固執する必要はありません。

同じインスタンス（内部の異なるタブ）で高架と非高架を混在させることはできません。

私は上記を誤解したかもしれませんが、私が読んでいるものとはまったく異なるユーザーコンテキストでターミナルを実行することにはプラットフォームの制限があります。

私は上記を誤解したかもしれませんが、私が読んでいるものとはまったく異なるユーザーコンテキストでターミナルを実行することにはプラットフォームの制限があります。

ええ、このスレッドはその点で全面的に使用されています。 私は自分のワークステーションの管理者ではないので、「管理者として実行」は単に「昇格された資格情報」を入力するように促します。

おそらく、そのユースケースに関する新しいスレッドが必要です。

明確にするために、私が意味するのは（そして、多くの「管理者」が必要だと思う）、通常のユーザーとしてワークステーションにログインできることです。 次に、AD作業を行うために、たとえばドメイン管理者のように、昇格したユーザーとして「いくつかのシェル」を実行します。

正しいか間違っているか、それは私たちの何人かがし、必要としていることです。 そのユーザーとしてストアからコンソールをインストールし、巧妙なショートカットを考案することに関するすべてのトリックは、私にとって実際にはうまくいきませんでした。

はい、これはさまざまな方法で実行できます。これらのアクティビティの一部を保護されたワークステーションに制限する必要があるかもしれませんが、通常のユーザーとしては、通常、シェルは必要ありません。

IMVHOの混乱は、人々が「昇格した」と「別の[ドメイン] [管理者]ユーザーとして」という用語を多かれ少なかれ交換可能に使用しているという事実から生じています。

別のユーザーとして実行することは、昇格して実行することと同じではありません。

1. このスレッドの一部のユーザーは、管理者ユーザーとしてログオンしたときに、昇格してWindowsTerminalワークロードを実行する必要があります。

2. 他の一部のユーザーは、通常の（またはドメイン管理者以外の）ユーザーとしてログオンしたときに、Windows Terminalワークロードを別の管理者ユーザーとして（通常は昇格で）実行する必要があります。

3. また、ユーザーが通常のユーザーAとしてログオンしていて、昇格せずにユーザーBとしてWindowsTerminalワークロードを実行したい場合も考えられます。

＃2と＃3では、Windowsターミナルはログオンしたユーザーとして実行されず、そのユーザーに「ストアアプリ」が展開されるため、Windowsストアベースの展開ではストーリーがより複雑になります。

私が状況を正しく理解していることを願っています。 もしそうなら、これが問題を少し明確にすることを願っています。

あなたはそれを正確に理解しました。

参考までに、その正確な問題は、ログインしているアカウントがシステムのローカル管理者ではない場合、昇格できません（別の管理者ユーザーとして実行するのではなく、「別のユーザーとして実行する」）。ベストプラクティスに従って）、別の問題で簡単に説明されました： https ：//github.com/microsoft/terminal/issues/1538。 これは、ストアアプリの制限のように思われるため、ターミナルの問題ではなく、Windowsの問題であるという説明で締めくくられました。

これがストアを使用する代わりにMSIインストールとしてリリースされるべきかどうかについて議論することなく、私が使用したそのスレッドには回避策があります。 管理者アカウントとして簡単にログインし、ストアからアプリをインストールしてから、再度ログアウトします。 次に、管理者として実行して、通常のユーザーアカウントで作業しました（次の更新まで、再度実行する必要があります）。

はい、MSIが利用可能である必要があります。 私の新しい雇用主は（パブリック）ストアのインストールを許可していないので、Windowsターミナルを使用できる唯一の方法はソースからビルドすることです...

エラーなしで「管理者として」Windowsターミナルを実行できず、回避策を実装する必要があることに失望しました。 多くの企業がIDに対して特権の分離アプローチを実装していると思います（ICT従業員は特権アカウントと非特権アカウントを持っています）。 したがって、 @ sba923の提案に従ってオプションのMSIデプロイメントを提供することでこの要件に対応できることは、そのようなタイムストアにバンドルされたアプリが特権の分離に対処できるようになるまでは適切なアプローチでしょうか？

これは、1.0リリースでもないプレビューです...

このトピックはこの時点でかなりよく議論されていると思いますが、まだ理解していない視点が1つあります。それは、このアプリへのWindowsショートカットを作成できないのはなぜですか。 これは、「常に管理者として起動する」ための一般的な回避策です。一般的な回避策は、ショートカットを作成し、デフォルトとして昇格されたアクセスを使用するようにショートカットを変更することです。

このアプリへのショートカットを作成できない理由を誰かに説明してもらえますか？ これはおそらく、ターミナルの内部動作よりもWindowsの内部動作に関連していると思われますが、直接質問しないと、私たちは茂みの周りを打ち負かしているように感じます。

ありがとう。

nircmdは、他の多くの一般的に使用されるツールと一緒にc：\ utilsフォルダーに保存します。
次のようなプロファイルを追加しました。

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

UAC昇格要求が表示され、Windowsターミナルの管理インスタンスが開きます。 今のところ、これは適切な回避策です。

正直なところ、セッションに昇格のタグを付けて、新しいウィンドウで開くことができれば問題ありません。

私はきちんとした解決策を探してここに来ましたが、それは存在しないように思われるので、ハッキーな解決策を共有します。 PowerShellを昇格させて実行するためのプロファイルを追加しました。

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

別のウィンドウにポップアップ表示されますが、作業は完了します。

このトピックはこの時点でかなりよく議論されていると思いますが、まだ理解していない視点が1つあります。それは、このアプリへのWindowsショートカットを作成できないのはなぜですか。 これは、「常に管理者として起動する」ための一般的な回避策です。一般的な回避策は、ショートカットを作成し、デフォルトとして昇格されたアクセスを使用するようにショートカットを変更することです。

このアプリへのショートカットを作成できない理由を誰かに説明してもらえますか？ これはおそらく、ターミナルの内部動作よりもWindowsの内部動作に関連していると思われますが、直接質問しないと、私たちは茂みの周りを打ち負かしているように感じます。

ありがとう。

@aaronsteers 、あなたはそれがターミナルよりもウィンドウズについてであるということは正しいです。 ここでの主な問題は、「最新のアプリケーションパッケージ」として配布およびインストールされていることです。 ネイティブアプリケーションと比較して、いくつかの制限と偶発的な制限がありますが、「最新のWindows API」（WinRT）のコンポーネントを使用する最も簡単な方法でもあるため、ターミナルに必要です。 ほとんどの場合、チームの全員にとって非常に苛立たしいことです。 ：笑顔：

私たちは、その欲求不満とコミュニティの欲求不満をプラットフォームの進歩に変えようとしています。 ただし、このWindowsでは、変更が迅速ではないことをお詫び申し上げます。

@DHowettターミナルが2/3好きなので、本当に理解しようとしていますが、TakeCommandやConEmuなどに慣れている基本的なことは何もしていません。

さまざまなタブで標高を混在させることはできません。 私が理解しているのは、あなたが別の種類のアプリであり、実際にシェルをホストしていないためですか？

スクロールバックバッファーは、3つの環境（cmd、PowerShell、wsl bash）のいずれでもクリアされません。通常のシェルではクリアされます。 繰り返しますが、それがどのようにホストされているのでしょうか？

また、コンテキストメニューまたはドロップダウンメニューにアクセスしやすくすると非常に便利です。 たとえば、そのスクロールバックをクリアするには、コンソールのエスケープトリックでさえもうまくいきませんでした。

環境の統合、およびそれがWSLLinuxシェルをどれだけうまく拾い上げるかは本当に素晴らしいです。 ただし、高度とスクロールバックの問題により、多くのユーザビリティが犠牲になるため、私はめったに使用しません。

@robomac @DHowettによるすばらしい投稿があります-MSFTは、同じ非高架ウィンドウで高架タブと非高架タブを混在させることができない理由を説明しています。

tl; drは次のとおりです。ユーザーが昇格されていないターミナルウィンドウから昇格されたコマンドラインに接続できるようにすると、ターミナルウィンドウを介して、昇格されていない他のアプリケーションが効果的に昇格されたプロセスを駆動できる巨大なセキュリティホールが作成されます。

ConEmuがこのリスクをどのように軽減するかは、仮にあったとしてもわかりません。 それがconemuによって作成されたセキュリティホールであり、Windowsターミナルの一部として出荷するのは快適ではない可能性があります。

残りの懸念事項は、このリポジトリの他の場所で追跡されているすべての問題です。個別に進捗状況を追跡するために、それらを検索することをお勧めします。 このスレッドは、「タブの高さの混合」/「高さで起動するプロファイルを持つ」という単一のトピックに留めておきたいと思います。

トピックについて：「昇格された」プロファイルに対して「別のインスタンスを昇格させて起動する」ルートを試してみたいと思います。 ユーザーエクスペリエンスがそれほど悪くない場合は、少なくともオプションとして、それがここでの可能なルートです。

ConEmuはこのリスクを軽減しません。 彼らはそのリスクをユーザーに転嫁します。 （彼らがこのリスクを文書化しているかどうかさえわかりません。）

「別のインスタンスを昇格して起動する」トピックについて：これらのタブにターミナルの同じ昇格されたインスタンスを使用でき、「昇格された」プロファイルを呼び出すたびに新しいインスタンスを起動しない限り、この動作は問題ありません。

私の意見では、そのセキュリティホールの「巨大さ」は少し誇張されています。 自分のコンピューターにマルウェアが存在し、昇格のチャンスを待っているのは普通ではないため、セキュリティのために利便性を犠牲にすることは適切ではありません。

一方、最終目標がWTをデフォルトの端末としてWindowsに同梱することである場合、攻撃対象領域が劇的に増加します。 しかし、繰り返しになりますが、この場合、私は個人的に、そのような攻撃の標的になる可能性が低く、必要な利便性を提供する人気のない代替手段を使用することによってリスクを軽減します（端末の高架タブの存在を検出することは十分に重要であると仮定します）端末固有であるため）。

これの一部は私にとってはtl; drですが、パッケージを取得してダンプすると、サンドボックスの外でwtを実行できます。つまり、昇格を意味し、別のユーザーが問題なく動作するように実行できます。 私はこれについて発火時にMSFTと話し、プルリクエストを提出するように言われましたが、私のVSスキルはかなり弱いです。 簡単にできることは、適切に署名し（applockerで実行できるように、独自の内部pkiを使用してこれを行う必要がありました）、MSIまたはMSIXの配布可能な形式で配置することです。 この方法で実行することに固有の奇妙なバグが所々にありますが、全体的には非常にうまく機能します。 今のところ、ストアベースのバージョンからプログラムファイルベースのバージョンを抽出、署名、置換/更新する機能があります。

高架タブを高架でないプロセスに「差し込む」という機能のリスクは理解していますが、その逆を行うことはできませんか？
人々がこれをどのように必要としているのかを考えて、ターミナル自体も高架として実行し、高架でないタブを開始できるようにしますか？
もちろん、それは他の不利な点もありますが、私にとって（そして私は他の人にとっても）それらは受け入れられます。
（確かに、ターミナルはWindowsストアアプリであるため、「興味深い」可能性があります。それが機能するかどうかはわかりません）

追伸この問題を再開して申し訳ありません（別の人がすでにその提案をしていて、私がそれを「読み返した」場合も）。

@EmTschiのおかげで、私はシンプルで100％便利なソリューションを作成しました
コンテキストメニューを使用し、PowerShell7とほぼ同じように機能します
https://github.com/nt4f04uNd/wt-contextmenu
そこにあなたはそれとすべての必要なファイルを実装する方法のガイドを見つけることができます

ヒントをありがとう、私は後でそれを試してみます。
現在、デスクトップで2つのショートカットを使用しています。これらのショートカットは、高架端末のCtrl + Alt + TキーとCtrl + Alt + Shift + Tキーにマップされています。回避策としても問題ありませんが、それほど良くありません。 sudoのようなものから何マイルも離れている可能性があります。

@

管理者アカウントでターミナルアプリを実行しようとすると、右クリック->管理者として実行すると、UACが2回ポップアップし、次のようなエラーが発生します。
「Windowsが（path \ WindowsTerminal.exe）を見つけることができません。入力したことを確認してください...」。
パスは存在し、アプリはアプリを作成した非管理者ユーザーに対して正しく機能しますが、他の管理者ユーザーはそれを実行できません。
管理者ユーザーにログインすると、ターミナルアプリは、システムにインストールされていないかのように、設定にもスタートメニューにも表示されません。
すべてのユーザーにインストールされるようにアプリを構築する方法はありますか？ または、プロジェクトのルートはユーザー固有ではないディレクトリにある必要がありますか？

同じ問題が発生しているのを見ています。

Windowsバージョン18922.1000

Win10アップデート1909にインストールしたばかりで、管理者として実行しようとすると同じ問題が発生します

ここでも同じ問題があります。 常にdockerを実行する必要があり、その後は常にターミナルの管理者である必要があるため、Windowsターミナルを使用できません...

私はそれを望む人のためのハックアラウンドソリューションを持っています：

1. リリースページからmsixbundleをダウンロードします
2. それを解凍し、そこで、プラットフォーム用のmsix（通常はx64のもの）を見つけます
3. それをどこかのフォルダに解凍します
4. そのフォルダを好きな場所にコピーして、WindowsTerminal.exeを昇格させて実行します。

この失敗の多くは、ストアアプリとしてこれを持っているという便利さから来ているようです。 これについては＃1386で議論されており、おそらく誰かが上記の抽出プロセスを自動化するScoopを使ってインストールすることに言及しています。

以下が一級市民として扱われたらいいのにと思います。

1. ポータブルインストール（zipファイル-構成がまだポータブルでない場合でも、Windowsストアのインストール領域が不足するとAppData \ Localの下に存在するため）
2. ストアを望まない、またはストアインストーラーを使用したくない人のための通常の古い.exeインストーラー（または、必要に応じて.msi）

Scoopの自動化で証明されているように、どちらも現在のビルド手順から実装するのはそれほど難しいことではありません。 そして今、Windowsターミナルは本当にかなり良くなっているので、他のターミナルと同じようにそれを使用できるようにしたいと思います。

私たちがそれに取り組んでいる間：APIの非互換性がない限り、以前のバージョンのWindows 10にストアなしで（「ポータブル」な方法でさえ）Windowsターミナルをインストールするオプションがあると素晴らしいでしょう（私の雇用主は1809 /で私たちをブロックしますRS5、およびストアからのインストールはブロックされています）。

@ sba923 1903にのみ存在するAPIに依存していなかった場合、1903は必要ありません。

確かに...私の推測でした😜

全社的にアップグレードするためにロビー活動を行う必要があり、おそらく壁にぶつかるでしょう...

これはとても愚かです。

コマンドプロンプト、PowerShell、およびWindows用のbash用の新しい統合端末を作成しましょう。
管理者としてcmd.exeを実行できますか？
いいえ。

cmd.exeとpowershellアイコンをプリセットして、タスクバーで管理者として無期限に実行できるようにすると思います。

このようなばかげたものが、私の主な作業用マシンがまだMacbookである理由です。

これはとても愚かです。

コマンドプロンプト、PowerShell、およびWindows用のbash用の新しい統合端末を作成しましょう。
管理者としてcmd.exeを実行できますか？
いいえ。

cmd.exeとpowershellアイコンをプリセットして、タスクバーで管理者として無期限に実行できるようにすると思います。

このようなばかげたものが、私の主な作業用マシンがまだMacbookである理由です。

この場合、私は同意します。 必要なすべてのターミナルタブを格納する単一のWindowsターミナルウィンドウが必要です。各ターミナルタブは、インストールされている複数のターミナルホストの1つであり、昇格されているかどうかは関係ありません。

この混合標高機能は、単一のHWNDハンドルですべてのタブをホストするという技術設計の決定によって実際に抑制されているようです。

1）新しいターミナルを管理者として実行できますか？ はい（インストール/起動方法によっては問題がありますが、これが機能しないことは望ましくありません）。 （これを行う方法がわからない場合は、上記の複数の投稿を参照してください。

2）1つのタブを高くして、別のタブを高くすることはできますか？ いいえ。 理由については、 https： //github.com/microsoft/terminal/issues/632#issuecomment-519375707を参照してください。

この問題は混合標高タブに関するものであることを覚えておいてください。 プロセス全体を昇格させて起動したいが、新しい問題を開くことができない場合。

@ DHowett-MSFTこの問題の名前を、混合標高タブに関するものに変更できますか？

これがどのように処理されるかどうかに関係なく、高架端子またはタブには何らかのインジケーターが必要です。 これで、[管理者として実行]を使用して新しいターミナルを起動した場合、次のウィンドウのコマンドタブと比較してコマンドタブのアクセスが昇格されていることに簡単に気付く方法はありません。

@SamuelEnglardのコメントの後で編集：明らかに私は急いで悪い例としてcmdを選びました。 はい、 cmdはタブタイトルに「Administrator：」と表示されます。 しかし、私のデフォルトタブのWSL Ubuntu bashは、タブタイトルにあるものをすべて上書きします。 bashはWindows Terminalの標高を知らない（または気にしない）ので、 bash内からタイトルを更新するときに情報を使用することはできません（もちろんsudoがあります）

ターミナルのprofiles.jsonには、
"showTabsInTitlebar": false
ただし、この設定では、ターミナルのタイトルバーは標高を示しません。

@janilahtiは昇格されたCMDタブが次のように見えない
あなたのために？

誰もあなたのツールを使いたくないのであれば、セキュリティは重要なポイントです...

Ya'llは、cmd.exeとpowershellの両方で機能するWindows用のsudoコマンドを作成する必要があります。 これにより、両方のショートカットを管理者として実行する手間を省くことができます。

参考までに、私はgsudoと呼ばれる$ sudo for windows $を作成しました： https ：//github.com/gerardog/gsudo

cmd / powershell / pwshコマンドまたはシェル全体の昇格をサポートします。 インストールと使用は簡単で、元の* nixsudoに似ている必要があります。 他にもsudoの実装がありますが、私見では、 gsudoが最も用途が広く使いやすいです。

たとえば、これを使用して、 gsudo cmd / gsudo pwshまたはgsudo WhateverShellを呼び出して昇格されたタブを起動するWTプロファイルを作成できます。 gsudoをインストールし、WTプロファイルを追加します。

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

これは、昇格されていないときにクライアントとして機能し、サーバーとして昇格されて起動するC＃クライアントサーバーアプリです。 両方のインスタンスは、保護された名前付きパイプを介して通信します。 他のウィンドウのsudoは、ほとんどの場合、新しいウィンドウをポップアップするPowerShellの「runas」スクリプトに似ていますが、完全なアプリであるため、はるかに多くの機能を追加できました。

スレッドを読み、sudoコマンドのセキュリティについて説明し、いくつかの有効なポイントを示しました。 私は考えられるすべてのセキュリティ対策を講じており、それらをさらに導入することをオープンに（そして計画して）います。 この時点で、リモート管理PSセッションを開く場合、または昇格されていないコンソールからssh root@serverを実行する場合と同じように、安全/安全でないはずです。 （たとえば、キーストロークや画面のスクレイピングに対して脆弱であり、間違っている場合は修正してください。ただし、* nix sudoもこのように脆弱であると理解しています）。 クレデンシャルキャッシュもあります。これは、5分間のセッション中のUACポップアップの量を減らします（* nix sudoに触発されています）。これは明らかに攻撃ベクトルであり、構成を介して無効にすることができます。 セキュリティについて心配している人のために、簡単なコマンドまたはエンタープライズグループのポリシー/レジストリ設定を使用して、セキュリティを強化する非常に簡単な方法を追加することを計画しています（資格情報キャッシュなどの機能を無効にすることによって）。

このコメントで指摘された興味深い点の1つは、Microsoftは「ユーザーの利便性のためにリスクを受け入れる」余裕がないということです。 それがMSからの最後の言葉である場合、少なくともこれはまともな（完全に機能する）回避策のように見え、セキュリティを改善する方法に関するすべてのフィードバック/問題またはアイデアを歓迎します。

公式にサポートされていないものをインストールする必要はありません。 企業環境でそれを使用する能力をすべて殺します。

次に、 @ hparadizは、セキュリティリスクなしで公式のsudo（または混合標高タブ）を可能にする新しいセキュリティ設計を備えた新しいバージョンのWindowsがリリースされるまで待つ必要があります。 それはすぐには起こらないようです。 ベストショットは、WT全体が管理者として起動され、＃4217で追跡され、より早くリリースされる可能性が高いまで待つことです。

ブログから素敵なハックを見つけました：

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

@gerardog gsudoのスクープバケットはありますか？ またはそれは既知のものの1つにありますか？ 私は現在Linuxボックスを使用しているので、確認できません。

@fluffynutsスクープのメインリポジトリにあります。 したがって、「scoop installgsudo」だけです。 また、他のインストール方法はhttps://github.com/gerardog/gsudoにリストされています。 しかし、WTのトピックについてこの議論を続けましょう。 😉

未解決の質問：高架タブと非高架タブを混在させることがセキュリティリスクである場合、そのリスクはConEmuに存在しますか？ それがまさにそれを行うことができるからです。 または、ConEmuは、ターミナルで行うのとは異なる方法でその機能を実装していますか？ そしてもっと広く言えば、ここで（このスレッドや他のスレッドで）要求されている機能の多くはすでに他の端末に存在していることに注意してください。ConEmuはほんの一例です。したがって、端末開発者がこれらの機能が実装されないか、実装されないことを示唆する場合非常に長い間、あなたは暗黙のうちにターミナルを使用すべきではないことを確認しているだけです。

1903年にのみ存在するAPIに依存していなければ、1903は必要ありません。

@ DHowett-MSFTこれらがどのAPIであり、なぜそれらが必要なのかに関する公開ドキュメントはありますか？ なぜなら、外部のオブザーバーとして、この決定とUWPを使用するという決定を見ると、付加価値が見当たらないからです。 多くのエンタープライズユーザーが基本的な機能と見なしているものを追加することへの障害が見えます。

@dadpolice ComEmuの機能については、 https： //github.com/microsoft/terminal/issues/632#issuecomment-518888895を参照してください。

Microsoftによれば、「UACはセキュリティバリアではない」と思いましたか？ Vistaのように扱われました。 それから、それは1つではないと言われ、このような問題はWindows 7のジョークでした。今日もまた1つですか？

この場合、ファイルエクスプローラーとUACホワイトリストの設計を確認する必要があるかもしれません。 :)

それとも、通常の開発者が許可されていないこと（ファイルエクスプローラー）を設計する際にショートカットを使用するか、重要な機能（この場合）を実装しないかどうかに依存しますか？

本質的な機能（この場合）を実装していませんか？

明確にしておきたいのですが、この機能を実装しようとはしていません。 それは確かに私たちが実装したい重要な機能です。 それは私が今毎日遭遇していることです-2番目の高いウィンドウを持つことは_大丈夫_ですが、それは_良い_ではありません。

適切に安全なソリューションを設計し、それを実際に実装するためのエンジニアリング作業も行うには、しばらく時間がかかります。 それは今週もしばらくの間ホワイトボードに載せたものです。

@ zadjii-msft

[...]
少しセキュリティホールであるため、高架タブと非高架タブの混合をサポートする予定はないと思います。
[...]

（関連するスレッドのリンクに関しては、＃146）

人々がその機能が実装されないという印象を受けていたのは奇妙なことです。 皮肉のサイン

@ kort3x 「計画なし」（別名、私たちはそれを約束していません）と、それを実装する方法を見つけるために彼らができることをしたくなくて実行することには違いがあります。

@ zadjii-msftが言ったように：

適切に安全なソリューションを設計し、それを実際に実装するためのエンジニアリング作業も行うには、しばらく時間がかかります。 それは今週もしばらくの間ホワイトボードに載せたものです。

安全なソリューションがない限り、混合標高タブをサポートする予定はありません（別名promise）。 私は、安全な解決策を持っている2番目の解決策が計画に追加されることを望んでいます（私は何も約束することはできませんが）。

Microsoftによれば、「UACはセキュリティバリアではない」と思いましたか？ Vistaのように扱われました。 それから、それは1つではないと言われ、このような問題はWindows 7のジョークでした。今日もまた1つですか？

私が理解しているように、「常に通知する」として構成されている場合はセキュリティバリアであり、そうでない場合はそうではありません。

まあ、これは残念です。 私はターミナルが好きです（私は一般的に非MSツールにかなり夢中になっているので、多くのことを言っています）が、スムーズに昇格できないことは、このOSでより多くの作業を行う上での本当の障壁です。

笑大丈夫そう、私はそれがどのように混乱しているのかを見ることができます。 私は当初、最初に発表してから数日後、計画がなかったときにそのコメントを書きました。 数ヶ月の議論の後、私は確かにこれが可能であるかもしれないという考えにもっと努力して思いついた。 それを反映するようにコメントを更新します。 @SamuelEnglardは正しいですが、正しく実行できることが_わかる_まで、これを実行することを_コミット_することは困難です。

これは聞いて励みになります。 この熱意を他のチームに広げることは可能ですか？それで＃3581は実際に修正できますか？

そもそもタブを異なるプロセス（Chromeが管理する方法と同様）にできると便利です。そうすれば、単一の環境を更新するためだけに、タブを適切にグループ化した後ですべてのタブを再起動する必要がなくなるからです。 cmdタブ..。
Windowsターミナルが単なるマネージャになると、昇格されたコマンドプロンプトを保持したまま、昇格されていないモードで実行できます。 それはいいね。 （まあ、上昇していない端子を保持しながらwtを上昇させても大丈夫です）

@ rapus95技術的には、「コンソール」が別のプロセスであるという点でタブがあります。 Windowsターミナルはすでに単なるマネージャーです

編集（2020年2月14日）
さて、このコメントはあまり古くなりませんでした。 もともと、これをサポートする計画はありませんでした。これは、私たちが持っていた単一のHWNDでは機能しないためです。 将来的にはこれをサポートする可能性のあるソリューションの設計に取り組んでいますが、適切に安全なソリューションを考え出すことができると確信するまで、何も約束できません。これにより、特権の低いプロセスでは不可能になります。より高い特権の端末を駆動します。

他のいくつかの点は別として、それが私がまだConEmuを使用している主な理由です。 そして、私はこれまでにそうするに違いない。
https://conemu.github.io/ @ Maximus5

これはとても愚かです。

コマンドプロンプト、PowerShell、およびWindows用のbash用の新しい統合端末を作成しましょう。
管理者としてcmd.exeを実行できますか？
いいえ。

このようなばかげたものが、私の主な作業用マシンがまだMacbookである理由です。

@hparadizConEmuを見てください：-D1つのウィンドウで複数のシェルをタブとして実行しても問題ありません。 昇格されていないものは別として、昇格されたPowershellおよびcmd.exeセッションを実行することもできます。

@tmeckelは、ターミナルチームが心配しているセキュリティの脆弱性がconemuにないことを確信していますか？ ユーザーは、自分が望むことを実行するため、安全性の低いソフトウェアを選択することがよくありますが、それは自分自身の危険にさらされます。

@ drdamour @ tmeckelそうです。 上記と同じ質問をしましたが、別のスレッドで回答されています： https ：//github.com/microsoft/terminal/issues/632#issuecomment -518888895

私はこれまでTerminalにかなり批判的でしたが、公平を期すために、ConEmuやConsoleZなどの同様のツールはすでに存在しています。 マイクロソフトが単にそれらをコピーすることにはほとんど価値がありませんが、安全な方法でそれらの機能を再作成することには大きな価値があります。 とはいえ、ターミナルエミュレーターをストア専用のUWPアプリとして構築するのは、まだ非常にばかげていると思います。特に、MicrosoftがUWPから離れつつあるようです（たとえば、新しいEdgeはWin32アプリです）。

とはいえ、ターミナルエミュレーターをストア専用のUWPアプリとして構築するのは、まだ非常にばかげていると思います。特に、MicrosoftがUWPから離れつつあるようです（たとえば、新しいEdgeはWin32アプリです）。

明確にするために、ターミナルはストア専用ではなく（ .msixはここで利用可能です）、UWPアプリケーションでもありません。 これは、UIフレームワークとしてUWPXAMLを使用するWin32アプリケーションです。

@ rapus95技術的には、「コンソール」が別のプロセスであるという点でタブがあります。 Windowsターミナルはすでに単なるマネージャーです

それでは、なぜ環境が新しいcmdインスタンス用に更新されないのですか？ 私は常に新しいWindowsターミナルを開く必要があります。これは、ある意味で、複数のタブを持つことの全体的なユーザビリティを低下させます...

@ rapus95は前向きではありませんが（コードを掘り下げる必要があります）、各サブプロセスは、新しい環境ではなく、親の環境で起動されると確信しています。

それはターミナルマネージャーにとって意味がないようです🤔

@ rapus95これは、実際にはここで追跡しているバグです：＃1125

明確にするために、ターミナルはストア専用ではなく（ .msixはここで利用可能です）、UWPアプリケーションでもありません。 これは、UIフレームワークとしてUWPXAMLを使用するWin32アプリケーションです。

これは、追加の手順を伴うUWPのように聞こえます。 それが何であれ、ターミナルを右クリックして別のユーザーとして実行することはできません。通常のWin32アプリケーションの場合とは異なり、これは奇妙な選択でした。

UWPアプリでもストア専用アプリでもありません。
たまたま配布方法の1つがStoreであり、UWPパッケージが必要です。
ストアを使用してインストールした人だけがRight click -> Run As Adminをインストールできません。
msixをアンインストールして、またはスクープ経由で使用します

msixをアンインストールして、またはスクープ経由で使用します

またはchocolatey 。

@gerardog管理者として実行するとは言いませんでしたが、別のユーザーとして実行すると言いました。

Shift + Right Clickはあなたのために働きませんか？

（ scoopを使用してインストールしたことに注意してください）

いいえ。msixパッケージを使用してインストールしましたが、そのオプションはありません。

私はchocolateyとしてインストールしましたが、管理者としても実行していません

明確にするために、ターミナルはストア専用ではなく（ .msixはここで利用可能です）、UWPアプリケーションでもありません。 これは、UIフレームワークとしてUWPXAMLを使用するWin32アプリケーションです。

これは、追加の手順を伴うUWPのように聞こえます。 それが何であれ、ターミナルを右クリックして別のユーザーとして実行することはできません。通常のWin32アプリケーションの場合とは異なり、これは奇妙な選択でした。

ここでも同じですが、msixとstoreアプリの両方を試しました。 「別のユーザーとして実行」オプションがまだありません。

すべての高架タブの背景色を赤にして、高架になっていることが明らかになるようにするにはどうでしょうか。

私はむしろこれを構成可能にしたい：背景色、タブタイトル...

https://github.com/gerardog/gsudoは一時的な解決策としてうまく機能します

たぶん、同じ環境の現在のシェルで新しい昇格されたウィンドウを開くwt elevatedのようなものを実装します。
編集：または＃3158が、新しいウィンドウとして昇格

Linuxのようにコピーしない理由がわかりません。

私の理解またはLinuxの世界（間違っている場合は訂正してください）では、suまたはsudoと入力してコマンドを実行しても、ターミナルアプリ（gnome-terminal、mate-terminal ...）を昇格する必要はありません。 rootユーザー。 ターミナルアプリの唯一の使命は、昇格されている、または昇格されていない別のプロセス（bash、ksh ...）でシェルを実行し、シェルと対話できるようにシェルの入力と出力をリダイレクトすることです。

Linuxターミナルで「su」と入力するか、「sudo」でコマンドを開始しても、別のウィンドウは開きません。

@gabsoftwareLinuxでもこれのセキュリティについてはよくわかりません。 LinuxのXウィンドウにもキーストロークを送信することができます。実行中のターミナルがsudoまたはsuで昇格されている場合でも、Xウィンドウで実行されているターミナルクライアントにキーストロークを送信できると思います。 高架Xウィンドウにキーストロークを送信することも可能かもしれませんが、私にはよくわかりません。

明確にするために、ターミナルはストア専用ではなく（ .msixはここで利用可能です）、UWPアプリケーションでもありません。 これは、UIフレームワークとしてUWPXAMLを使用するWin32アプリケーションです。

これは、追加の手順を伴うUWPのように聞こえます。 それが何であれ、ターミナルを右クリックして別のユーザーとして実行することはできません。通常のWin32アプリケーションの場合とは異なり、これは奇妙な選択でした。

ここでも同じですが、msixとstoreアプリの両方を試しました。 「別のユーザーとして実行」オプションがまだありません。

スタートメニューのタイルをShiftキーを押しながら右クリックして「別のユーザーとして実行」することはできませんが、Shiftキーを押しながら右クリックしてWindowsTerminal.exeをクリックすると実行できます。

@gabsoftwareLinuxでもこれのセキュリティについてはよくわかりません。 LinuxのXウィンドウにもキーストロークを送信することができます。実行中のターミナルがsudoまたはsuで昇格されている場合でも、Xウィンドウで実行されているターミナルクライアントにキーストロークを送信できると思います。 高架Xウィンドウにキーストロークを送信することも可能かもしれませんが、私にはよくわかりません。

私はいくつかの実験を行いましたが、今ではLinuxでのこれの不安定さをかなり確信しています。 私はセキュリティの専門家ではないので、これが何を意味するのかわかりません（誰か？）。 sudoを実行したばかりで、パスワードを要求せずに新しいsudoコマンドを開いているXウィンドウにキーストロークを送信するのは非常に簡単です。 ここにブログ投稿、恥ずべきプラグをごめんなさい...

私の結論は、混合標高ウィンドウへのキーストロークの送信を禁止する方法がない限り、これはリスクを受け入れる意思のあるユーザー（大きな太った警告サインなど）のオプションとしてのみ実装する必要があるということです。

ちなみに、Windowsのオンスクリーンキーボードはどのようにしてキーストロークを高架ウィンドウに送信しますか？

gsudo v0.7をリリースしましたが、このスレッドに関連しています。

編集：コンテキストの場合： gsudoはWindowsのsudoであり、現在のコンソールで単純なコマンドまたはシェルを昇格させることができます。 WT内のCmd / Pwshから呼び出されると、タブが上がります。 また、プロファイルを編集して「Elevated Powershell」という名前を付け、コマンドをgsudo Powershellに変更すると、昇格されたタブプロファイルが作成されます。 ここを参照してください。

ただし、gsudo、またはWindowsの場合はsudoがUAC分離を飛び越えるため、「安全でない」というラベルが付けられています。 以下は、セキュリティを維持しながらタブの高さを混在させることができる、より複雑な回避策です。 /編集終了

gsudoは、任意の整合性レベルでアプリケーションを起動できるようになりました。 たとえば、 MediumPlus整合性レベルでWindows Terminalを起動できます。これは、「半昇格」モードを意味します。管理者権限はありませんが、他の通常の（Medium Integrity）プロセスからは分離されています。 （UACポップアップが表示されます）

したがって、最初のステップは常にWTを次のように起動することです： gsudo -i MediumPlus WT
（WTショートカットを変更できます）。 これにより、悪意のあるプロセス、画面スクレイピング、sendkeys、dll-injectionなどからWTが保護されます。
（編集：機能しない場合は、 gsudo -n -i MediumPlus cmd /c cmd /c start wtを使用してください）

次に、WT内でgsudoを安全に使用してコマンドを昇格させるか、profiles.jsonで"commandline": "gsudo cmd.exe"を使用して昇格したプロファイルを作成することもできます。

私の結論は、混合標高ウィンドウへのキーストロークの送信を禁止する方法がない限り、これはリスクを受け入れる意思のあるユーザー（大きな太った警告サインなど）のオプションとしてのみ実装する必要があるということです。

完了しました。 （gsudoにセキュリティ警告を追加しました）。

また、ユーザーが通常/中程度の整合性プロセスからgsudoを呼び出している場合、 gsudoの資格情報キャッシュ（UACポップアップを少なく表示する機能）を完全に保護することはできないことを知ったので...キャッシュは、 gsudo cache on/offまたはgsudo config cachemode autoを介して明示的に有効にする必要があります。

"Changing your WT shortcut"は決して些細なことではありません。MSIX/ AppStoreモデルを考えると、＃4217と＃4459に遭遇しました。

次のPowerShellスクリプトは、これらの問題を回避して、デスクトップにWindowsターミナルのショートカットを作成し、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()

MediumPlusとしてWTを開始したら（つまり、Ctrl + Alt + T）、[上記]（https://github.com/microsoft/terminal/issues/632#issuecomment-613751789）で説明したようにgsudoを使用してコマンドを昇格させることができますAFAIKが安全であるべきもので。

これに対する私の回避策は、 LukeSamsonの_SudoforWindows_を使用することです。 プロファイル構成は次のとおりです。
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
そのプロファイルで新しいタブを開始すると、UACがポップアップ表示され、Powershellコアが昇格します。 他の端末でも動作します。
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
スクープを使わないのなら、コンセプトを抽出して独立して使うことができると思います。 ここでソースコードを確認してください： https ：//github.com/lukesampson/psutils/blob/master/sudo.ps1

schtasksの回避策を使用して、Windowsターミナルを管理者として実行し、UACをバイパスしています。

1. タスクスケジューラを起動します。
2. 新しいタスクを作成します。 名前を付けて、[最高の権限で実行する]チェックボックスをオンにします。
   

3. [アクション]タブで、プログラムの開始を選択します： wt

4. [設定]タブで、[タスクをオンデマンドで実行することを許可する]がオンになっていることを確認し、[より長く実行している場合はタスクを停止する]チェックボックスをオフにします。

5. デスクトップを右クリックしてショートカットを作成し、[新規]-> [ショートカット]を選択して、 schtasks.exe /run /TN "{task name}"と入力します
   
6. 必要に応じて、ショートカットアイコンを変更し、タスクバーにドラッグします。

これが修正されるまで、cmderに固執する必要があるようです。

おそらく計画のインクリングがあるので、ドキュメントを入手できますか
現在の計画がないとは言わないように更新されましたか？

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

@drdamour計画ができたら、そのセクションを削除したいと思います。 しかし、今のところ、計画を立てる方法を研究する計画しかありません。 実際の計画があり、それを安全に実行できる方法ができたら、そのセクションを削除します。

@KMorazによって記述された方法は、今のところ回避策としてうまく機能します。 これを投稿していただきありがとうございます。

やあみなさん、

昨日これを発見するまで、私はConsoleZを使用していました。
ConsoleZにはいくつかの機能があり、1つは、UACを使用して管理者として新しいタブを開始することです（UACのダイアログが表示されます）。
新しい高架タブを開くためにキーボードの手を握る必要がないので、私はそれが非常に便利だと思います。

プロファイル構成内の構成だった場合はどうなりますか？ これがConsoleZで行われる方法です。

こんにちは、みんな、

管理者として何かを実行するときにローカル管理者のクレデンシャルを入力する必要がある人にとっては、シンプルでうまく機能する別のショートカット回避策を見つけました。

このリンクは説明していますが、wt.exeリファレンスのフルパスが必要です。
http://nuts4.net/post/windows-terminal-run-as-admin

私の完全なショートカット文字列は次のとおりです： C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

2020年5月21日更新：
上記は、バージョン1.0.1401.0より前で機能していました。

この新しい問題も参照してください： https ：//github.com/microsoft/terminal/issues/6013

ローカル管理者アカウントで昇格する必要がある場合も、Crtl-Shiftクリックは機能しません。

権限の昇格を2回求められた後に表示される、以下のエラースクリーンショットを参照してください。

詳細については、imho gsudoがこれに最適です、thx https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

私の設定には、特権を取得するためのこのプロファイルのみがあります：

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

私にとって、管理者としてWindows Terminalを開く最も簡単な方法は、タスクバーの最初の項目として固定することです。 次に、 Win+Ctrl+Shift+1が管理者として開きます

私にとって、管理者としてWindows Terminalを開く最も簡単な方法は、タスクバーの最初の項目として固定することです。 次に、 Win+Ctrl+Shift+1が管理者として開きます

確かに非常に便利ですが、これはAdministratorsグループのメンバーであるアカウントに対してのみ機能します。

他のユーザーの管理者を務めている場合、そのユーザーのアカウントから（管理者）ユーザーとしてWindowsTerminalを実行することはできません。

すべてではなく、管理者としてcmdを実行するために1つのタブを設定するとよいと思います。

すべてではなく、管理者としてcmdを実行するために1つのタブを設定するとよいと思います。

ここで他の場所で説明されているように、これは現在の設計では不可能です。

管理者として実行するために使用できるフラグはありますか？ 次に、そのショートカットを作成するだけです。

Windows Terminalをタスクバーに固定すると、Ctrl + Shift +クリックを使用して_elevated_で起動できます。

これは、アイコンを右クリックし、[Windowsターミナル]を右クリックして、[管理者として実行]を選択するのと同じことを行います。

注：Windowsターミナルはストアアプリであるため、_別のユーザー_として実行することはできません。

各プロファイルのオプションとして整合性レベルを使用して、Windowsターミナルで「混合整合性レベルのタブ」を使用できるようにしたいと思います。 これは主に、ワークフローの中断とコンテキストの切り替えを最小限に抑えるための通常のsysadmin / devops作業の便宜のためです。

私は今のところ私のために働く簡単な代替案を見つけました。 これは、他のユーザーによってここに提示されたすべてのシナリオに対応しているわけではありません。 サードパーティのアプリ、ショートカットファイル、キーの組み合わせ、またはスケジュールされたタスクには依存しません。 Windowsターミナルの実行可能ファイルの場所を特定する必要はありません。 昇格した2番目のWindowsターミナルインスタンスを起動するWindowsターミナルプロファイルリストに別のエントリを作成するだけです。 これにより、UACプロンプトが1回トリガーされます。 これは、仰角が必要な場合にのみ使用します。

その結果、2つのWindowsターミナルが作成されます。 一方のすべてが標準で、もう一方のすべてが昇格されます。 私にとって、これは許容可能なレベルの中断とコンテキスト切り替えです。 昇格されたWindowsターミナルでは、各タブタイトルの前に「Administrator：」が追加され、違いを視覚的に確認できます。

編集：Powershell7をインストールしています。

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

@ IarwainBen-adar、最近、新しいドキュメントを読んで、 commandlineアイテムとsourceアイテムを一緒に使用できないことを思い出したようです。 sourceアイテムがなくても、期待どおりに機能しますか？

私は彼のコードを試しましたが、プルに新しいアイテムを表示することさえできません
ダウンメニュー。

@ shem-sargent申し訳ありませんが、無関係なsource宣言が実際に問題だったため、ここでコメントを削除しました。 メニューエントリが機能しているので、残念ながらWindowsターミナルの昇格されたインスタンスを起動できません— The file cannot be accessed by the system.の失敗で問題＃3145が発生しています

@ IarwainBen-adar申し訳ありませんが、＃3145を再現できません。 それ以外の場合は、自分の側でトラブルシューティングを試みます。

タスクバーに固定し、Shiftキーを押しながら右クリックします

乾杯@LordFPL 、そしてもちろん@gerardog 、私はこれまでgsudo（興味のある人はhttps://github.com/gerardog/gsudo）のことを聞いたことがありませんでしたが、これにより、高架セッションが簡単になりました。 ありがとう！ 設定ファイルのプロファイルオブジェクトに追加するか、Linuxシステムで行うようにsudoエイリアスを使用します。 完全！

@ zadjii-msft申し訳ありませんが、ここでの問題が何であるかを正確に理解していません。 Windowsはトークンの操作と偽装をサポートしていますが、ルーン文字はどのように機能するのでしょうか。 @gerardogのgsudoを使用すると、PowerShell、pwsh、cmd、またはwslシェルなど、他のレベルの整合性シェルと同時に、高整合性シェルをホストする低整合性wtを使用できます。 私の限られたテストから、整合性の低いシェルはどれも、整合性の高いシェルにデバッグできません。 これを組み込み端末として、またはOSレベルでさらに望ましい機能として使用するための障害は何ですか？

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

低整合性ウィンドウ_入力を受け取り、それを高整合性プロセスに直接ファネルする_は、システム上の他の低整合性のものによって制御されるまで、その高整合性プロセスを開きます。

これは、潜在的に悪意のあるプロセスがEoPを取得するために、同じ特権レベルで横方向に移動するだけでよいことを意味します。

@ smokeintheshell ＃632（コメント）

低整合性ウィンドウ_入力を受け取り、それを高整合性プロセスに直接ファネルする_は、システム上の他の低整合性のものによって制御されるまで、その高整合性プロセスを開きます。

これは、潜在的に悪意のあるプロセスがEoPを取得するために、同じ特権レベルで横方向に移動するだけでよいことを意味します。

はい、スレッドの冒頭でその説明を読みましたが、Linux、おそらくMacでは問題ないのに、Windowsでは問題がない理由がわかりません。 Windowsは現在、昇格されたプロセスへの入力を昇格されていないプロセスから保護しています。 この問題または関連する問題のいずれかで、誰かがタブごとに個別のプロセスが必要であると提案しました。 各タブには実行する独自のコマンド（例：pwsh.exe）があるため、これはすでに当てはまると思います。 それらはすべて、1つのHWNDの下で同じルートプロセスの子であるためですか？

私が次のいずれかを行った場合、Ubuntuの端末はタブに関して同じ問題を抱えていますか？

• suが開いているタブがあります
• すでにsudoで昇格したタブがあり、構成ポリシーに従ってPWを再度入力する必要はありませんか？

それとも、Ubuntuのアーキテクチャは、クロスプロセス入力インジェクション攻撃に対して何らかの形で強化されていますか？

私が次のいずれかを行った場合、Ubuntuの端末はタブに関して同じ問題を抱えていますか？

* 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?

それとも、Ubuntuのアーキテクチャは、クロスプロセス入力インジェクション攻撃に対して何らかの形で強化されていますか？

ここで私のコメントを見ると、私は実際にLinuxでこの問題を再現/悪用しています。 suとsudoはどちらも、これらのコマンドを実行している整合性の低いウィンドウにキーストロークを送信できるという点で、おそらく同じように「脆弱」です。 sudoパスワードタイムアウト（15分以内に次のsudoコマンドでパスワードを入力する必要がない）により、これがさらに簡単になります。 攻撃に必要なX拡張機能を無効にすることで、Ubuntuを強化できます。 これがウェイランド環境（攻撃および/または強化）で可能かどうかはわかりません。

仮想キーボードやその他のソフトウェア入力方法を無効にする方法がない限り、高さの混合タブを実装しないという決定を完全に理解しています。

各タブには実行する独自のコマンド（例：pwsh.exe）があるため、これはすでに当てはまると思います。 それらはすべて、1つのHWNDの下で同じルートプロセスの子であるためですか？

@kbirgerはい、タブごとに個別のプロセスがありますが、すべてのマウスとキーボードの入力は引き続きWindowsターミナルのウィンドウ（整合性が低い）に送信され、標準の入力ストリームを介して各シェルプロセスにルーティングされます。 これが、WindowsTerminalのすべてのキーボードショートカットの仕組みです。

たとえば、 GetCurrentInputMessageSource APIを使用して、入力が偽造されているかどうかを検出できるかどうか疑問に思います。 公式の例以外にこのAPIに関する多くの情報を見つけることはできませんが、説明から入力ソースを特定できるはずです（ハードウェア/ uiAccessを使用するプロセスから、主にアクセシビリティソフトウェア/ uiAccessを使用しないプロセスから、おそらく悪意のある）

Linux、そしておそらくMacには問題ないのに、Windowsには問題があるのはなぜですか？

3つの理由の1つは、Microsoftがセキュリティを機能として他の大企業や政府に販売していることだと確信しています。

それが今まで問題にならなかった理由について、私の頭に浮かぶ他のいくつかの理由もあります。

• 長い間、そして何らかの理由（「ハッカー」がWindowsを好まない、「全員」がWindowsを使用している^^など）では、Windowsはあらゆる種類のマルウェアの主要な（≈唯一の）標的でした。 他の人はそれほど気にしませんでしたが、それはより良いセキュリティ（高い窓を保護する）を必要としました。
• この号の前半で説明したように、マルウェアがWindows上の昇格したコンソールホストに簡単にアクセスすることはできなかったはずなので、その問題に投資した人はあまりいない可能性があります（私はセキュリティの専門家ではないので、わかりません）持っている場合）
• マルウェアは通常、選択したOSで昇格したコマンドプロンプトを見つけようとする以外に、自分自身を昇格させる方法があります。
• 開発者とシステム管理者のみが端末を使用します（これにより、攻撃の対象となる人口統計が減少するだけです。政府や大企業は依然として懸念事項です）

さて、この機能を素朴に導入することで（私たち全員が行ったように、私は確信しています😄）、いくつかのWindowsインストールに新しい（巨大な）欠陥を導入することになります。 開発がオープンに行われているので、必要としているすべての人が欠陥を認識し、それに対してコーディングを開始することを確信できます。
迅速な対策は、Windowsターミナル（および欠陥が公開された現在、他のすべてのターミナルエミュレーター）を禁止することです。その後、あらゆる種類の企業環境でWindowsターミナルを使用するという夢に別れを告げることができます😟

この機能の安全なバージョンが日の目を見ることを私はまだ非常に望んでいますが🤞

分かりました。 説明ありがとうございます！

ちなみに、Windowsのオンスクリーンキーボードはどのようにしてキーストロークを高架ウィンドウに送信しますか？

@mrwensveen AFAIK高架ウィンドウに入力を送信するには、次の3つの方法があります。

1. 自分を高めなさい。 ただし、システムプロセス（タスクマネージャー、UACダイアログ、ログイン画面など）に入力を送信することはできません。
2. Windowsサービスを登録します。 これで、プログラムはSYSTEMとして実行されるため、やりたいことが何でもできます。 私はいくつかのリモートアクセスプログラムがこれを行うのを見てきました。
3. uiAccessフラグを宣言し、バイナリにデジタル署名し、現在のユーザーが書き込みできない場所にインストールします。 これは、ユーザー補助ソフトウェアの「バックドア」であり、他のプログラム（システムプロセスを含む）の読み取り/書き込みを可能にし、他のウィンドウ（UACポップアップが表示されるセキュアデスクトップやログイン画面を含む）の上に、すべて昇格せずに表示できるようにします。 https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverviewを参照してください。

オンスクリーンキーボード（osk.exe）、Narrator.exe（およびおそらく他のスクリーンリーダー）はすべてメソッド3を使用します。

（ uiAccess=trueを含むosk.exeの埋め込みプログラムマニフェストを示すスクリーンショット）

uiAccessフラグは、他の低整合性プログラムによるアクセスからプログラムを保護することもできるようです（まだ昇格されていない状態で実行されているにもかかわらず）、おそらくこの「機能」を使用してWTを保護できますか？

@ yumeちゃんかっこいい、おもしろい、ありがとう！ uiAccessプログラムは、他のuiAccessプログラムにキーストロークを送信できますか？ OSKがWindowsターミナルと対話できるようにしたいのですが、これがWindowsターミナルへの入力の送信を許可する前に、他のプログラムに少なくとも署名する必要があることを意味する場合、それは十分に高い障壁ですか？

uiAccessプログラムは他のuiAccessプログラムにキーストロークを送信できますか？

@mrwensveenはい、 uiAccess特権を持つプログラムは相互にアクセスできます。

GetCurrentInputMessageSource APIの方法（https://github.com/microsoft/terminal/issues/632#issuecomment-651114562）が好きです。これは、 uiAccessの使用目的ではないためです。 また、APIを使用すると、整合性の低いプログラムがキーストロークを昇格されていないタブに送信できるようにすることができますが、昇格されたタブには送信できません。

私がここで行った小さな回避策：

いくつかの優れた機能を備えたPowerToysをインストールしました。 そのうちの1つは、Windowsのショートカットを表示することです。Win+番号を押すと、バーに表示される番号に対応するWindowsバーでアプリが開くことを発見しました。

だから、私は最初のアイコンとしてターミナルをバーに置きました
。

Win + 1を押すと、ターミナルが開きます。

Win + Ctrl + Shift + 1を押すと、昇格して開きます。

プロンプトにgitブランチとconda環境を表示し、昇格した端末の場合はユーザーを赤で表示する機能を取得したい場合は、端末の構成とPowerShellプロファイルもここに配置します...

これは、少なくともWindows7以降に存在します。 PowerToysのものではありません。

@Firehawkeはい、PowerToysのおかげで発見しました...どうしても必要ありません。

これは、Windows Storeで動作し、適切なアイコンが付いた、昇格された起動のプロファイルです。

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

編集：このスニペットのさまざまなコンポーネントについては、@ glooms 、@ shem-sargent、@ LordFPL 、および@Firehawkeの功績によるものです。 このコマンドはpwsh.exeを呼び出すため、PATH環境変数が破損しているか、パス内のpowershell.exeという名前の奇妙なバイナリが原因で、＃4228（起動時に0x80070002エラー）が発生したようです。 powershell.exeまたはpwsh.exe 。 @zurkz powershell.exeを参照してこれを修正しましたが、今は信頼できないと思います。 ＃6684は、Windows Terminalのこの問題に対処しており、その解決策に従って、この問題がまったく発生しないはずの修正バージョンを以下に示します。

これは、Windows Storeで動作し、適切なアイコンが付いた、昇格された起動のプロファイルです。

{
    "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それはうまくいきます！ ありがとう。

これは、Windows Storeで動作し、適切なアイコンが付いた、昇格された起動のプロファイルです。

{
    "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❤💯

これは、Windows Storeで動作し、適切なアイコンが付いた、昇格された起動のプロファイルです。

{
    "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私の無知を許してください、これはWindowsストアの構成にドロップされますか？ もしそうなら、誰かがパスを投稿できますか？ そうでなければ、この悪い男の子はどこに住むことになっていますか？

TYIA！

@カザマリオ
これは、Windowsターミナルのsettings.jsonファイルのプロファイルセクションにあります。

起動時に0x80070002というエラーが発生します。 pwsh7.1。

私はそれを次のように変更しました：

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

そしてUACは許可を上げるように促しました。

私はそれを次のように変更しました：

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

そしてUACは許可を上げるように促しました。

それは私にとって非常にうまくいきました。 ありがとう！

スタートに固定されている場合、Windowsターミナルを昇格して起動する方法は次のとおりです。
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@ narfanar ＃4228に遭遇したようです。この場合、PATH環境変数が混乱したり、他のバイナリがpowershell.exeという名前のパスに浮かんでいると、Windowsターミナルが起動時にエラー0x80070002を発行します。またはpwsh.exe 。 @zurkzのスニペットは、潜在的な問題をpwsh.exeからpowershell.exeにシフトするだけなので、これを実際に修正するとは思いません。 ＃6684はWTでこれを修正したので、そのソリューションに合わせて調整されたスニペットを次に示します。

{
    "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はこれをうまくやっています

Cmderにはこの機能があり、非常に便利です。 それがWindowsターミナルに実装されるのを見たいです。 [管理]タブなどのために別のウィンドウを起動する必要がある場合でも。

私のデフォルトのプロファイルは、PowerShellではなくbashに設定されており、そのままにしておきたいと思います。 上記のスニペットはうまく機能しますが、idは、PowerShellプロファイルが読み込まれた状態で新しい高架端末を起動できるようにするのが大好きです。 iveはこれを理解するために3時間ほど費やしました（PowerShellの大ファンではない/多くの経験があります）そして私はそれを理解することができません-助けてください。 一重引用符、二重引用符、エスケープ、スペース、改行の組み合わせがあるようですが、それでうまくいくかもしれませんが、start-processとargumentlistでやりたいことができません。 iveはそれを煮詰めました：

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
これは.ps1ファイルで機能します。自分で実行すると、PowerShellプロファイルが読み込まれた新しい昇格されたWindowsターミナルが表示されます。 ただし、settings.jsonのコマンドラインパラメーターでは機能しません。どのようにマングルしようとしても、cmd / cを使用する代わりにargumentlistを明示的に呼び出したり、さまざまな形式のエスケープや引用符の使用法などを使用したりします。

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
動作しません。 私ができる最善のことは、私が欲しいものの奇妙なハイブリッドを起動することです。 「Administrator：Ubuntu」ウィンドウが読み込まれます。これは私のbashプロファイルのように見えますが、実際にはPowerShellを実行しています。 間違ったフォントとすべて。 そのウィンドウを使用して新しいPowerShellタブを開くと、必要に応じて表示されます。 このようにすると、プロファイルの読み込みの「Windows PowerShell」部分に必要なゴミを貼り付けることができ、まったく同じ動作が得られるので、渡したプロファイルを実際に読み込もうとしていないことがわかります。

したがって、これを昇格として実行しようとすると問題が発生します。上記のすべてのオプションを実行すると、「ファイルが見つかりません」というエラーまたはこれが発生します。

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

まだ問題が発生している、またはこれらを正常に実行できていない人はいますか？

私のデフォルトのプロファイルは、PowerShellではなくbashに設定されており、そのままにしておきたいと思います。

私も。 私はほとんどの場合WSLを実行していますが、時々PSを昇格させて実行する必要があり、新しいWTのタブで実行したいと思います。

また、ファイルパスを修正しても、どの例も機能させることができませんでした。 現在のタブを昇格できるgsudoを見つけてインストールしたり、同じウィンドウで昇格したタブを開くためのプロファイルとして使用したりできます。 上記の解決策が新しいウィンドウで開始されたかどうかはわかりません（ gsudoを使用する前に行ったいくつかの試みは、新しいウィンドウでのみ開始されます）。 UACポップアップが開きます。

これは私が使用しているプロファイルです：

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

私はsupressApplicationTitleを使用しているので、タブのタイトルにはAdministrator：が表示されません。

@ayfine https://github.com/microsoft/terminal/issues/632#issuecomment -663686412が実際に機能しない場合は、その構成で発生する正確なエラー/予期しない動作の文字起こしを送信できますか？ （ suppressApplicationTitleなどの追加の構成をできるだけ小さなステップで追加して、構成のいずれかがWTに違反している場合に、どこでいつ発生しているかを簡単に判断できるようにしてください。）

ここにある他の構成がリンクされている構成よりもわずかに進んでいる場合は、それらがどのように壊れているかについての詳細もいただければ幸いです。

@ bb010gエラーメッセージが表示されません。返信が正確でなかったことをお詫びします。 https://github.com/microsoft/terminal/issues/632#issuecomment -663686412を使用しているときに、WSL Ubuntuシェル（デフォルト）をロードするWindowsターミナルの問題が発生しました。 私はこれを元々正しく機能していないことを意味すると考えていましたが、新しいウィンドウで新しい（デフォルトのプロファイル）Powershellタブを開始すると、実際には昇格されていることがわかります。 とにかく、新しいウィンドウを開くことと、その中で新しいタブを開始することの両方によって、スタートメニューから昇格したプロセスを実行するよりも簡単ではありません。 私が最初の返信で説明したことは、私が想像していた正確な動作を提供します。

@ ayfine-そして私はあなたのgsudoの例をコピーしました。 これは、組み込みのものがコーディングされるまでは十分な解決策です。 ありがとう。

@ayfine gsudoを試してみましたが、かなりひどい経験です。 あらゆる種類のTAB補完が壊れているようで、Unicode（非ASCII）文字が表示されていないようです。 入力と出力をリダイレクトし、それでひどい仕事をするのはある種のプロセスだと思います。 別のウィンドウを使用したソリューションの方がうまくいくと思います。

gsudoで問題が発生した場合は、このスレッドではなく@gerardogに報告してください。 このスレッドのすべてのメッセージ（これが含まれています。申し訳ありません！）は、何百人ものサブスクライバーに電子メールを送信します。

さらなるコメントが議論を意味のある量に進めない点に到達しているので、私はこのスレッドをさらなる非メンテナのコメントにロックするつもりです。

ここに記載されていない懸念がある場合は、新しい問題を提出してください。