Terminal: [سؤال] تكوين ملف تعريف Windows Terminal لإطلاق مرتفع دائمًا

لا يوجد. لا أعتقد أننا نخطط لدعم علامات التبويب المختلطة المرتفعة وغير المرتفعة ، لأنها نوع من الثغرة الأمنية.

نعم ، أعرف أن sudo شيء ما ، لكننا أجرينا الكثير من المناقشات مع فريق الأمان حول إنشاء sudo لنظام التشغيل Windows. ترجع المشكلة الرئيسية إلى حقيقة أن أي عمليات لم يتم رفعها يمكن أن ترسل ضغطات المفاتيح إلى أي نوافذ أخرى غير مرتفعة.

إذا كان لديك سطر أوامر مرتفع يعمل في نافذة غير مرتفعة ، فيمكن لممثل سيء غير موثوق به تنفيذ هجوم رفع الامتياز عن طريق قيادة النوافذ غير المرتفعة التي تشغل سطر الأوامر المرتفع.

(كمسألة ربط المواضيع ذات الصلة ، # 146)

EDIT (فبراير 14 2020)
حسنًا ، لم يكن هذا التعليق مع تقدم العمر جيدًا. في الأصل ، كانت هناك _لا توجد خطة لدعم هذا ، لأنه لن يعمل مع الفرد HWND الذي كان لدينا. نحن نعمل على تصميم حل قد يدعم هذا في المستقبل ، لكن لا يمكننا الالتزام بأي شيء حتى نتأكد من أنه يمكننا التوصل إلى حل آمن بشكل مناسب ، يضمن عدم قدرة العملية ذات الامتيازات المنخفضة قيادة محطة امتياز أعلى.

يبدو معقولا. أعتقد أن وجود شيء مثل مزيج من # 576 (فتح كمسؤول في قائمة الانتقال السريع) ، وربما نوعًا ما من مفاتيح التشغيل السريع لبدء جلسة المسؤول في Terminal من شأنه أن يحل معظم ألمي هنا.

ماذا عن فتح محطة طرفية قياسية ومرتفعة في نافذة واحدة ولكن في علامات تبويب منفصلة؟

mdtauk أعتقد أنه لسوء الحظ يندرج تحت نفس الفئة. نظرًا لأن جميع علامات التبويب موجودة ضمن نفس HWND ، فإن الجذر HWND هو ما يجب رفعه لمنع التطبيقات غير المرتفعة من قيادة النافذة.

من وجهة نظر الأمان (تجاهل تصميم Windows Terminal ، وجذر واحد HWND وما إلى ذلك) ، ما مدى "أقل أمانًا" في تشغيل Terminal لعلامات تبويب ذات ارتفاعات مختلطة مقارنة بتشغيل ، على سبيل المثال ، مثيل PowerShell مرتفع بجوار مثيل غير مرتفع في UX الحالي ؟ حقيقة أن تطبيقات وحدة التحكم مستضافة في علامات تبويب Terminal لا تُحدث فرقًا بالنسبة لي ...

في ملاحظة مماثلة: كيف يكون وجود نافذة غير مرتفعة أكثر أمانًا حتى لو فتحت جلسة PS عن بُعد حيث قد يكون لدي الآن امتيازات المسؤول على خادم بعيد يمكن أن يقودها الآن غير مرتفع. بالنسبة لي ، يبدو هذا أسوأ بكثير من الحصول على وصول مسؤول محلي ، لذلك لا أعتقد أن تشغيل علامة تبويب كمسؤول يختلف عن الاتصال عن بُعد / ssh-ing في خوادم أخرى. في كلتا الحالتين ، أحتاج إلى الشعور بالراحة الكافية مع نظامي للقيام بذلك. إنه شيء "أنا كبير في السن وأدرك المخاطر".

كلما حاولت تشغيل تطبيق Terminal باستخدام حساب مسؤول ، انقر بزر الماوس الأيمن -> تشغيل كمسؤول ، تنبثق UAC مرتين ويحدث خطأ يقول:
"يتعذر على Windows العثور على (المسار \ WindowsTerminal.exe) تأكد من كتابة ...".

المسار موجود ويعمل التطبيق بشكل صحيح للمستخدم غير المسؤول الذي أنشأ التطبيق ، لكن المستخدم المسؤول الآخر غير قادر على تشغيله.
إذا قمت بتسجيل الدخول إلى المستخدم المسؤول ، فلن يكون التطبيق الطرفي موجودًا في الإعدادات أو قائمة البدء ، كما لو لم يتم تثبيته مطلقًا على النظام.

هل هناك طريقة لإنشاء التطبيق بحيث يتم تثبيته لجميع المستخدمين؟ أم أن جذر المشروع يجب أن يكون في دليل غير مستخدم محدد؟

@

كلما حاولت تشغيل تطبيق Terminal باستخدام حساب مسؤول ، انقر بزر الماوس الأيمن -> تشغيل كمسؤول ، تنبثق UAC مرتين ويحدث خطأ يقول:
"يتعذر على Windows العثور على (المسار \ WindowsTerminal.exe) تأكد من كتابة ...".

المسار موجود ويعمل التطبيق بشكل صحيح للمستخدم غير المسؤول الذي أنشأ التطبيق ، لكن المستخدم المسؤول الآخر غير قادر على تشغيله.
إذا قمت بتسجيل الدخول إلى المستخدم المسؤول ، فلن يكون التطبيق الطرفي موجودًا في الإعدادات أو قائمة البدء ، كما لو لم يتم تثبيته مطلقًا على النظام.

هل هناك طريقة لإنشاء التطبيق بحيث يتم تثبيته لجميع المستخدمين؟ أم أن جذر المشروع يجب أن يكون في دليل غير مستخدم محدد؟

أرى نفس المشكلة تحدث أيضًا.

إصدار Windows 18922.1000

حسنًا ، لا يعمل تشغيل تطبيقات المتجر كمسؤول أو مستخدم مختلف (حسب التصميم راجع للشغل). يقوم الكثير منا بتسجيل الدخول (إلى الكمبيوتر الشخصي) كحساب عادي غير مرتفع. نقوم بتشغيل بوويرشيل / cmd / إلخ كمسؤول للقيام بمهام معينة.

إذا كان الخيار الأخير هو نشر هذا التطبيق هو متجر Windows ، فهو عديم الفائدة بالنسبة لي بدون طريقة لفتح علامات تبويب مرتفعة. 2 سنتي.

قد يكون "عديم الفائدة" قاسيًا بعض الشيء ، لكننا في الواقع نحتاج إلى طريقة لاستخدام الجهاز الطرفي الجديد للتطبيقات / الأصداف غير المرتفعة والمرتفعة. وبالنسبة لي ، فإن أفضل تجربة مستخدم هي دعم مزيج من علامات التبويب المرتفعة وغير المرتفعة في نفس مثيل Windows Terminal. أقل تفضيلًا: دعم صفر إلى العديد من المثيلات المرتفعة (عادةً واحدة) (كل منها يحتوي على علامة تبويب واحدة إلى عدة علامات تبويب) جنبًا إلى جنب من صفر إلى العديد من المثيلات غير المرتفعة (عادةً واحدة).

ConEmu قادر على مزج علامات التبويب المرتفعة وغير المرتفعة في نفس النافذة. ألا يمكن القيام بشيء من هذا القبيل هنا؟

هل يمكن أن يكون لدينا علامات تبويب غير مرتفعة لإطلاق Terminal؟ ما زلت بحاجة إلى إطلاق مرتفعة ولكن يمكنني فتح علامة تبويب جديدة "محمية".

إذا أردنا أن نتعامل مع Windows بشكل خاص وتجاهل الأنظمة الأساسية الأخرى التي قد ترى في النهاية Terminal ، فربما يساعد استخدام حاويات Windows أو العمليات الافتراضية في نقطة الألم هذه بالنسبة للبعض. أنا شخصياً على ما يرام مع الحل الحالي ولكن تشغيل تطبيقات وحدة التحكم كعمليات معزولة افتراضيًا لن يكون فكرة سيئة من وجهة نظر الأمان.

الارتفاع المختلط في نافذة واحدة أمر لا بد منه ، بالنسبة لي على الأقل.
هل يمكن أن تكون ميزة اختيارية يتم تبديلها في الإعدادات؟

pratnala مع ConEmu ، يبدو الأمر وكأنه يفعل ذلك فقط ، لكنه لا يفعل ذلك على الإطلاق. "علامات التبويب" المرتفعة وغير المرتفعة هي مجرد عروض في إطارين / عمليات جذر منفصلة تمامًا ومعزولة. يقوم بذلك عن طريق تجريف محتويات النوافذ من بين أشياء أخرى ومساعدو الوكيل / الوسيط وما إلى ذلك. بالتأكيد ، هذا ممكن تقنيًا ، لكن ما يفعله ConEmu هو في الواقع غير آمن نوعًا ما. يعد القيام بذلك أمرًا واحدًا بالنسبة لبرنامج جهة خارجية وجعل الأشخاص يختارون المخاطرة عن طريق تنزيل ConEmu ، ولكن شيء آخر تمامًا بالنسبة لـ Microsoft لتأييد ذلك رسميًا من خلال القيام بذلك بنفسها. إذا كنت أرغب في إخفاء مفاتيح الباب الأمامي الخاص بي تحت ممسحة الباب ، فلا بأس - هذه هي مخاطرة الغبية. ولكن ماذا لو وضع كل باب اشتريته مجموعة من المفاتيح تحت ممسحة الباب؟

لكن انظر ، لقد قمت بالتطوير في C ++ (و C # ، PowerShell ، Ruby ، ​​Python ، GoLang ، إلى حد كبير أي شيء يأتي في طريقي). أعرف الطريقة التي أمسك بها المقص أثناء الركض.

بوويرشيل _ هو ثغرة أمنية. أداة أتمتة مفيدة للغاية ، تسمح لجميع أنواع الوصول غير المتوقع. وما نطلبه (أوضاع مختلطة) هو بالتأكيد أكثر أمانًا من البديل (كل شيء مرتفع.) حقًا هذه (المحطة الطرفية) هي أداة طاقة لمستخدمي الطاقة ، الذين ربما يفهم معظمهم المشهد الأمني ​​جيدًا ... ويتفهمون حل وسط عملي.

لا تعمل الثقة المعدومة إلا عندما لا تكون منهكة.

robomac إذا تمكنا من إقناع فريق الأمن (الذي أخبرنا في مناسبات متعددة بعدم المغامرة عن بعد بالقرب من الارتفاع المختلط) أن الأشخاص الذين يعرفون كيفية حمل مقصهم بالطريقة الصحيحة وعدم الركض معهم هم فقط من يمكنهم استخدام هذا المشروع ، ربما سنفعل ذلك. لا أعرف ما إذا كنت أعتقد ذلك بنفسي. هذا هو السبب:

كما لم يكن الأمر كذلك ، إذا كانت الوحدة الطرفية تعمل في ارتفاع مختلط (من مضيف متوسط ​​IL إلى عميل IL-High) ، فلا يزال من الممكن إجبارها على تلقي المدخلات من قبل أي شيء آخر يعمل مثل هذا المستخدم. حتى لو كان الشخص الذي يقف خلف لوحة المفاتيح قديسًا ولم يرتفع إلا لمدة عشر ثوانٍ تحتاج إلى ترقيتها ، _ يمكن لأي تطبيق يعمل ضمن حساب المستخدم الخاص بها انتحال صفة المسؤول دون مطالبة إضافية بالارتفاع_. من المحتمل أن تكون غير مكتشفة تمامًا ، حتى.

@ DHowett-MSFT أشكركم على الرد. أنت تفترض أننا نسمح بتشغيل العمليات الضارة على أي حال. نحن نقيّد الأذونات من عبارات "أفضل الممارسات" التي نستخدمها مع وضع الكلب المتجه لأسفل كل صباح ، ولكن إذا كان لديك قلق حقًا من أن بضع ساعات ، حتى ، من الوصول المرتفع إلى المحطة الطرفية يعرضك للخطر - على نظامك الخاص الذي أنت تتطور في _ ...

1. لا يجب أن تقوم بتشغيل Terminal و
2. يجب أن تمسح وتبدأ من جديد.

سأمنحك أن باحث فيروسات (كمبيوتر) لا يجب أن يخاطر بهذا في مسار متجه ... ولكن حتى في وقت مبكر كنا نضعهم في وضع الحماية في أجهزة افتراضية. لكن "المحطة الطرفية" ليست لأقاربك البسطاء ؛ إنها أداة قوية.

هناك طريقة معيارية للتعامل مع المخاطر. يقدمه لك عالم المتصفح. عندما تذهب إلى الأعلام المتقدمة ، تتلقى تحذيرًا تقريبًا ، "هنا تنانين". (أعتقد أن هذا هو بالضبط في Pale Moon ... وهو متصفح الأمان الجاد.) أضف تحذيرًا (إضافيًا بخلاف UAC) ، لكن دع المستخدم يقرر.

سؤال آخر: هل ستعمل جلستان منفصلتان من Terminal ، واحدة مرتفعة ، والأخرى لا ، كما هو متوقع؟ أم أن كلاهما سيكون متجهًا لأي جلسات؟

لا أوافق على وجوب تمكين الأشخاص من الاشتراك في شيء كهذا. :ابتسامة:

جلستين متميزتين

أوه ، نعم ، يجب أن يعمل هذا تمامًا اليوم - ولا يكون ناقلًا (يعمل المرتفع بشكل كامل على جانب High-IL من العالم ولا يمكن أن يكون مدفوعًا بأي عملية متوسطة IL أخرى)

يجب أن يعمل هذا اليوم تمامًا

وبنفس الروح ، ألا يمكن تشغيل علامتي تبويب في عمليات مختلفة وبالتالي تمكين ارتفاع مختلط في نفس النافذة؟

@ DHowett-MSFT فلماذا لا يمكن استضافة الجلستين المميزتين في التطبيق الشامل؟ حقًا ليس من الصعب القيام بذلك.

أعتقد أنني أفهم الآثار الأمنية لامتلاك تطبيقات وحدة تحكم مرتفعة في المقام الأول ، ولكن ما لا يمكنني فهمه هو السبب في أن وجود نوعين من علامات التبويب (مرتفعة وغير مرتفعة) داخل Windows Terminal سيكون _ أكثر خطورة_ مما يدعمه Windows للأعمار ، على سبيل المثال ، تشغيل CMD المرتفع وغير المرتفع / PowerShell جنبًا إلى جنب. يمكن للشخص يلقي بعض الضوء على هذا؟

تضمين التغريدة
[1] إنه أمر تافه عندما _ تستضيف النوافذ التقليدية _ بمقابض النوافذ التقليدية. يعمل هذا جيدًا في حالة conemu ، أو في حالة الغلاف المبوب ، حيث يمكنك تولي نافذة في جلسة مرتفعة وإعادة ترتيبها تحت نافذة في جلسة غير مرتفعة.

عندما تفعل ذلك ، هناك بعض ميزات الأمان التي سأتطرق إليها في [2]. بسبب هؤلاء ، يمكنك تربية الأبوين ولكن لا يمكنك إجبارها على فعل أي شيء.

بالرغم من ذلك ، هناك مشكلة. لم تتم هندسة Terminal كمجموعة من النوافذ القابلة لإعادة الاستخدام. على سبيل المثال ، لا يقوم بتشغيل مضيف وحدة التحكم ونقل نافذته إلى علامة تبويب. تم تصميمه لدعم "اتصال" - شيء يمكنه قراءة النص وكتابته. إنها بدائية ذات مستوى أدنى من النافذة. لقد أدركنا الخطأ في طرقنا وقررنا أن نموذج UNIX كان مناسبًا طوال الوقت ، وأن الأنابيب والنصوص والتدفقات موجودة في مكانها.

نظرًا لأننا نستخدم جزر Xaml لاستضافة واجهة مستخدم حديثة وخياطة سطح DirectX فيها ، فإننا بعيدون جدًا عن عالم مقابض النوافذ القياسية على أي حال. تتكون جزر Xaml بالكامل في HWND واحد ، مثل Chrome و Firefox وسلسلة ألعاب DirectX / OpenGL / SDL. ليس لدينا مكونات يمكن تشغيلها في عملية واحدة (مرتفعة) واستضافتها في عملية أخرى (غير مرتفعة) ليست "الاتصالات" المذكورة أعلاه.

الآن ، سؤال المتابعة الواضح هو _ "لماذا لا يمكنك الحصول على اتصال مرتفع في علامة تبويب بجوار اتصال غير مرتفع؟" _ هذا هو المكان الذي يجب أن يلتقط فيه @ sba923 القراءة (: smile :). ربما سأقوم بتغطية بعض الأشياء التي تعرفها بالفعل (robomac).

[2] عندما يكون لديك نافذتان على نفس سطح المكتب في نفس محطة النافذة ، فيمكنهما التواصل مع بعضهما البعض. يمكنني استخدام SendKeys بسهولة من خلال WScript.Shell لإرسال مدخلات لوحة المفاتيح إلى أي نافذة يمكن لـ shell رؤيتها.

تشغيل عملية رفع _severs_ هذا الاتصال. القذيفة لا ترى النافذة المرتفعة. لا يوجد برنامج آخر على نفس مستوى التكامل مثل الغلاف يمكنه رؤية النافذة المرتفعة. حتى لو كان لديه مقبض نافذته ، فإنه لا يمكنه التفاعل معه حقًا. هذا هو السبب أيضًا في أنه لا يمكنك السحب / الإفلات من المستكشف إلى المفكرة إذا كانت المفكرة تعمل بشكل مرتفع. يمكن فقط لعملية أخرى مرتفعة التفاعل مع نافذة مرتفعة أخرى.

ميزة "الأمان" هذه (أطلق عليها ما تريد ، ربما كان المقصود منها أن تكون ميزة أمان عند نقطة واحدة) موجودة فقط لعدد قليل من أنواع الكائنات العامة للجلسات. النوافذ واحدة منهم. الأنابيب ليست في الحقيقة واحدة منهم.

لهذا السبب ، من التافه كسر هذا الأمان. خذ المحطة كمثال على ذلك. إذا بدأنا اتصالاً مرتفعًا واستضفناه في نافذة "غير مرتفعة" ، فقد أنشأنا فجأة قناة عبر حدود الأمان تلك. الشيء المرتفع على الطرف الآخر ليس نافذة ، إنه مجرد تطبيق لوضع النص. يقوم فورًا بتقديم العطاءات للمضيف غير المتقدم.

أي شخص يمكنه التحكم في المضيف غير المرتفع (مثل WScript.Shell::SendKeys ) _ أيضًا_ يحصل على قناة فورية عبر حدود الارتفاع. فجأة ، يمكن لأي تطبيق متوسط ​​النزاهة على نظامك التحكم في عملية عالية النزاهة. قد يكون هذا هو متصفحك ، أو عامل منجم البيتكوين الذي تم تثبيته مع حزمة left-pad من NPM ، أو أي عدد من الأشياء.

إنها مخاطرة صغيرة ، لكنها _هي_ مخاطرة.

قبلت المنصات الأخرى هذا الخطر في تفضيله لراحة المستخدم. إنهم ليسوا مخطئين في فعل ذلك ، لكنني أعتقد أن Microsoft تحصل على قدر أقل من "النجاح" في أشياء مثل "قبول المخاطرة لراحة المستخدم". كان Windows 9x بمثابة كارثة أمنية غير قابلة للتخفيف ، وكانت حسابات المستخدمين المحدودة ومطالبات الارتقاء والأمان على مستوى kernel لإدارة النوافذ هي الإجابة على هذه الأشياء. إنها ليست أقفال ليتم فكها بسهولة.

@ DHowett-MSFT شكرا جزيلا للتوضيح. أعتقد أنه سيتعين علينا التعود على تشغيل مثيل واحد مرتفع من Windows Terminal ومثيل واحد غير مرتفع جنبًا إلى جنب ، مثلما نفعل مع تطبيقات وحدة التحكم هذه الأيام.

مبهر. شكرا لك. تعتبر المحطة الطرفية بمثابة عارض اتصال أكثر من كونها نافذة أمرًا منطقيًا. هل يمنح ذلك PowerShell ، الذي يركز بالفعل على الأنابيب / الاتصال ، أي تحكم إضافي سابق في وحدة التحكم ذات الإطارات؟

هل الجلسات الطرفية المنفصلة معزولة تمامًا عن بعضها البعض؟

سأكون راضيًا تمامًا عن مجرد وجود إشارة إلى أنني في جلسة مرتفعة. مثل "المسؤول: \ أنا أفتقد هذا السوء جدًا الآن.

؟؟؟

"تشغيل كمستخدم مختلف" هو شيء يحتاجه جميع مشرفي Windows! سيكون هذا مفيدًا جدًا إذا كان متاحًا. سيكون الخيار الأفضل هو الحصول عليه بعلامة في التكوين لكل ملف تعريف.

راجع للشغل ، عند الحديث عن عزل النافذة ، اسمحوا لي أن أقتبس من أحدث تقرير عن ضعف ctfmon

الهجوم الواضح هو قيام مستخدم لا يتمتع بامتيازات بحقن أوامر في جلسة وحدة تحكم المسؤول ، أو قراءة كلمات المرور أثناء تسجيل دخول المستخدمين. حتى عمليات AppContainer التي يتم وضع الحماية لها يمكنها تنفيذ نفس الهجوم.

ecki هذا خبر مزعج تمامًا. أنا متأكد من أن تافيس سيتوقف عن الاحتفال الليلة بعد ذلك.

@ DHDHowett-MSFT
كما كتب الكثيرون هنا ، إذا لم يكن الجهاز الجديد قادرًا على البدء بخيار "تشغيل كمستخدم مختلف" عن عدد كبير من المستخدمين ، فلن يكون قابلاً للاستخدام ، كما أنه غير متوافق مع "نموذج الطبقة الإدارية لـ Active Directory" من Microsoft إذا كان لديك على سبيل المثال مستخدم AD يتمتع بحقوق افتراضية ، وقمت بتشغيل PS Scripts مع Adminuser على وحدة تحكم المجال.

ليس لدي العديد من الحالات التي أبدأ فيها تشغيل Terminal مع المستخدم المسجل حاليًا الخاص بي ... لذلك أسألك ، ما هي حالة استخدام هذه الوحدة الطرفية من؟ Ping، nslookup وما إلى ذلك .. إذا كانت هذه هي النية ، فلماذا تبذل الكثير من الجهد في كل هذا؟

مع "تشغيل كمسؤول" لديك بعض النقاط الصحيحة ، ولكن لماذا لا تزال وحدات التحكم الأخرى مثل (PS6 / 7) تدعم هذه الوظائف ، إذا كانت غير آمنة؟

اعتقدت دائمًا أن تطبيق Terminal الجديد سيحل محل جميع نوافذ cmd / PS /… المنفصلة ، ولكن يبدو أنه غير قابل للاستخدام في العديد من سيناريوهات العالم الحقيقي. هذا نوع من الحزن tbh ...

Fisico تجربتك ليست عالمية ، وأنا أشجعك على التفكير في ذلك عندما تطلب من شخص ما تبرير وجود مشروعه ذاته.

إلى النقطة الرئيسية الخاصة بك حول "تشغيل كمستخدم مختلف" غير موجود / لا يعمل: هذا أحد قيود النظام الأساسي الذي نحاول رفعه. ليس من خلال الحقد أو عدم الكفاءة أننا لا ندعمها.

بالنسبة لسبب دعم تطبيقات وحدة التحكم الأخرى _do_ ، فهي ليست آمنة عندما تفعل ذلك لأنها لا تستضيف على وجه التحديد مستويات ارتفاع مختلفة في نفس النافذة. هذه هي القضية الأساسية هنا. نظرًا لاستضافتها في عمليات قائمة بذاتها بنوافذ مستقلة ، فهي خالية من القيود المفروضة على التلاعب عبر مستوى التكامل.

@ DHowett-MSFT
آسف إذا أساءت إليك من خلال منشوري ، لم يكن ذلك في نيتي ، لقد وضعت الكثير من العاطفة فيه.
أعتقد أن Terminal هي فكرة رائعة ولديها إمكانات كبيرة جدًا وأنا سعيد لأنك تطورها مع المجتمع لتحقيق أقصى استفادة منها.

في هذه المرحلة ، هناك الكثير من الالتباس حول ما يتم تنفيذه وما لا يتم تنفيذه.
"تشغيل كمسؤول" للتطبيق بأكمله يعمل في الوقت الحالي ، هل هذا موجود لتبقى؟

كما أفهم ، فإن "تشغيل كمسؤول" لكل علامة تبويب / ملف تعريف ليس شيئًا تريد تنفيذه. أعتقد أن هذا جيد بالنسبة لمعظمنا.

"تشغيل كمستخدم مختلف" غير ممكن لأن Windows لا يدعمه للتطبيقات ، وعليك / علينا الانتظار حتى يدعمه Windows؟ إذا كان الأمر كذلك فهل نتحدث عن سنوات؟

"تشغيل كمستخدم مختلف" لكل علامة تبويب / ملف تعريف هو أيضًا شيء لا تريد تنفيذه؟

@ DHDHowett-MSFT
كما كتب الكثيرون هنا ، إذا كانت المحطة الجديدة غير قادرة على البدء بالخيار "تشغيل كمستخدم مختلف"
من عدد كبير من المستخدمين ، فهو غير صالح للاستخدام ، ... اعتقدت دائمًا أن تطبيق Terminal الجديد سيفعل ذلك
استبدل جميع نوافذ cmd / PS /… المنفصلة ، ولكن كما يبدو أنها غير قابلة للاستخدام في العديد من سيناريوهات العالم الحقيقي. هذا نوع من الحزن tbh ...

أنا لا أوافق. هذا تقدم كبير عما كان لدينا من قبل. لسوء الحظ ، ربما اعتاد معظمنا على رفع قذائفنا بسبب عدم وجود نهج أكثر دقة ... وما زلنا نستطيع ذلك. لا يمكننا خلطهم ... لكننا لم نفعل ذلك أبدًا. على محمل الجد ، في آخر ثلاث شركات كنت أعمل فيها ، قام Developer Wiki بإجراء جميع الإنشاءات / الاختبارات في موجه VS مرتفع. نحن نطبق الأمان من خلال عمليات الفحص في الوقت الفعلي ، وجدران الحماية النشطة القوية ومعرفة أن مطورينا نادرًا ما يخطئون. لا يعمل _ غير المطورين_ مطلقًا على مستوى عالٍ ، لأن (1) لا يمكننا الوثوق بهم و (2) لا يحتاجون إلى ذلك.

لذلك أنا شخصياً أقدر هذه المحطة الجديدة. إنها ليست مثالية ، لكن الأمر ليس كذلك / Take Command / TCC. على الأقل هذا هو المعيار.

@ DHDHowett-MSFT
كما كتب الكثيرون هنا ، إذا كانت المحطة الجديدة غير قادرة على البدء بالخيار "تشغيل كمستخدم مختلف"
من عدد كبير من المستخدمين ، فهو غير صالح للاستخدام ، ... اعتقدت دائمًا أن تطبيق Terminal الجديد سيفعل ذلك
استبدل جميع نوافذ cmd / PS /… المنفصلة ، ولكن كما يبدو أنها غير قابلة للاستخدام في العديد من سيناريوهات العالم الحقيقي. هذا نوع من الحزن tbh ...

أنا لا أوافق. هذا تقدم كبير عما كان لدينا من قبل. لسوء الحظ ، ربما اعتاد معظمنا على رفع قذائفنا بسبب عدم وجود نهج أكثر دقة ... وما زلنا نستطيع ذلك. لا يمكننا خلطهم ... لكننا لم نفعل ذلك أبدًا. على محمل الجد ، في آخر ثلاث شركات كنت أعمل فيها ، قام Developer Wiki بإجراء جميع الإنشاءات / الاختبارات في موجه VS مرتفع. نحن نطبق الأمان من خلال عمليات الفحص في الوقت الفعلي ، وجدران الحماية النشطة القوية ومعرفة أن مطورينا نادرًا ما يخطئون. لا يعمل _ غير المطورين_ مطلقًا على مستوى عالٍ ، لأن (1) لا يمكننا الوثوق بهم و (2) لا يحتاجون إلى ذلك.

لذلك أنا شخصياً أقدر هذه المحطة الجديدة. إنها ليست مثالية ، لكن الأمر ليس كذلك / Take Command / TCC. على الأقل هذا هو المعيار.

مرتفعة! = تشغيل كمستخدم مختلف.
أقوم بتشغيل PowerShell أكثر مع مستخدمي AD الآخرين ، ثم مع مستخدمي AD الآخرين.
أنا معك لأنك غالبًا ما تقوم بتشغيل cmd أو PS كمسؤول حتى لو لم تكن مضطرًا لذلك ، ولكن هناك العديد من الحالات التي يتعين عليك تشغيلها كمسؤول. تتطلب معظم مهام مسؤول النظام حقوق المسؤول أو مستخدمًا مختلفًا له نوع من الامتيازات.
بالتأكيد إذا كنت بحاجة إلى تشغيل أوامر cmd في سياق المستخدم ، فكل شيء على ما يرام.

أفهم أن "مرتفعة! = تشغيل كمستخدم مختلف". أنا فقط لا أعتقد أن "تشغيل كمستخدم مختلف" أمر شائع كما تدعي.

أفهم أن "مرتفعة! = تشغيل كمستخدم مختلف". أنا فقط لا أعتقد أن "تشغيل كمستخدم مختلف" أمر شائع كما تدعي.

إذا كان لديك شيء لتفعله بعالم Microsoft فأنت في حاجة ماسة إليه.
ليس من الأفضل تسجيل الدخول إلى أجهزة windows باستخدام حقوق مسؤول المجال على سبيل المثال.
يعد تشغيل نصوص PS مع مستخدم لديه حقوق domainadmin أو بعض الحقوق الأخرى أمرًا شائعًا جدًا.

Fisico لماذا لا تستخدم الأمر New-PSSession إذن؟

تتطلب البرامج النصية الآلية التي تتطلب نوعًا معينًا من الارتفاع لخدمة ما عادةً "تشغيل كمستخدم مختلف". ما إذا كان هذا ينطبق على Terminal هو قصة مختلفة. يمكنك دائمًا تغيير تسجيل الدخول مرة واحدة في جلسة CMD أو PS باستخدام الأمر runas . لن يؤدي هذا إلى تغيير حالة ارتفاع علامة التبويب لأنها تستخدم تسجيل الدخول الأساسي ، وهو المستخدم العادي الخاص بك. وأيضًا أي نصوص تقوم بتشغيلها باستخدام برنامج جدولة المهام أو مهمة cron لن تتطلب تشغيل Terminal إلا إذا كنت تستخدمها للحصول على وظيفة غير موجودة بطريقة ما في جلسة وحدة التحكم العادية. إذا كان الأمر كذلك ، فإن استخدام المعلمات لتشغيل هذا البرنامج النصي مع Terminal ، والذي يتم تشغيله كعملية في الخلفية سيكون هو الحل.

لذلك فإن الارتفاع المختلط لعلامات التبويب ليس ضروريًا. لدينا حل بديل وهو سهل بما يكفي لنسخ أوامر runas المحددة التي تحتاجها إلى ملف txt يمكنك نسخه / لصقه في Terminal ثم ملء كلمة المرور الخاصة بك (لا يجب عليك أبدًا حفظ كلمة مرورك في أي شيء غير مشفر).

تضمين التغريدة
لا أريد الاتصال بمضيف بعيد لتشغيل برنامج نصي.

WSLUser نعم ، إنه خيار لاستخدام runas ، ولكن من الملائم أكثر أن تقوم ببساطة بتشغيل المحطة أو PS كمستخدم مختلف. لا أفهم لماذا يجب أن يكون هذا مشكلة.

Fisico New-PSSession ليس بحاجة إلى الاتصال بجهاز كمبيوتر بعيد ، راجع الإدخال الثاني الأول في بناء الجملة.

تضمين التغريدة
لا أريد الاتصال بمضيف بعيد لتشغيل برنامج نصي.

WSLUser نعم ، إنه خيار لاستخدام runas ، ولكن من الملائم أكثر أن تقوم ببساطة بتشغيل المحطة أو PS كمستخدم مختلف. لا أفهم لماذا يجب أن يكون هذا مشكلة.

إنها عملية قياسية جدًا للمستخدم لتثبيت PowerShell على شريط المهام والنقر بزر الماوس الأيمن للتشغيل كمسؤول أو في بعض البيئات ، يلزم تشغيل RunAs OtherUser كحساب مرتفع للتشغيل والبرامج النصية على مستوى المؤسسة. إن القول بأن الجهاز غير ممكن مثل البيئات التي تستفيد من PSLockDown وتجبر RunAs Admin فقط على تحميل shell أو VSCode
IMHO

إذا كنت تحتاج حقًا إلى تشغيل علامة تبويب كمستخدم مختلف ، فيمكن أن يكون لديك ملف تعريف يعمل New-PSSession -Credential | Enter-PSSession في البداية.

إخلاء المسؤولية : أنا لا أتحمل أي مسؤولية عن أجهزة الكمبيوتر التي تعرضت للتلف بسبب القيام بذلك.

إذا كنت تحتاج حقًا إلى تشغيل علامة تبويب كمستخدم مختلف ، فيمكن أن يكون لديك ملف تعريف يعمل New-PSSession -Credential | Enter-PSSession في البداية.

> إخلاء المسؤولية : أنا لا أتحمل أي مسؤولية عن أجهزة الكمبيوتر التي تضررت من القيام بذلك.

بالتأكيد ، أو يمكن إعادة النظر في الوضع "الأمني" هنا. مرة أخرى ، أقوم بتثبيت PowerShell على شريط المهام الخاص بي ، ومن هناك يمكنني تشغيل PowerShell غير المرتفع ؛ يمكنني النقر بزر الماوس الأيمن فوق ذلك واختيار "تشغيل كمسؤول" وإذا كنت في بيئة شركة يمكنني النقر بزر الماوس الأيمن فوق الرمز ، ثم انقر بزر الماوس الأيمن فوق "Windows PowerShell" وحدد "تشغيل كمستخدم مختلف" لتشغيل PowerShell بأوراق اعتماد بديلة. لا جلسات ، لا RDP'ing إلى مضيف آخر للحصول على تلك الاعتمادات.

بالتأكيد ، أو يمكن إعادة النظر في الوضع "الأمني" هنا. مرة أخرى ، أقوم بتثبيت PowerShell على شريط المهام الخاص بي ، ومن هناك يمكنني تشغيل PowerShell غير المرتفع ؛ يمكنني النقر بزر الماوس الأيمن فوق ذلك واختيار "تشغيل كمسؤول" وإذا كنت في بيئة شركة يمكنني النقر بزر الماوس الأيمن فوق الرمز ، ثم انقر بزر الماوس الأيمن فوق "Windows PowerShell" وحدد "تشغيل كمستخدم مختلف" لتشغيل PowerShell بأوراق اعتماد بديلة. لا جلسات ، لا RDP'ing إلى مضيف آخر للحصول على تلك الاعتمادات.

نعم ، ويمكنني أيضًا القيام بذلك باستخدام Windows Terminal. متفق. لا أرى كيف يساعد ذلك أولئك الذين يرغبون في الحصول على مزيج من علامات التبويب التي تعمل كمستخدمين مختلفين (أو ارتفاع مختلف).

بغض النظر عن "علامات التبويب المختلطة" ، أريد فقط أن أوضح ، لا يمكنك فعل ذلك مع (المعاينة التي تم إصدارها) Windows Terminal نظرًا لتصميم تطبيقات Windows Store. يمكنك فقط تشغيل المستخدم الذي ثبَّت هذا التطبيق وسجل دخوله باعتبارك ذلك المستخدم نفسه.

كل ما أريده هو أن أكون قادرًا على القيام بما أفعله اليوم ، وتسجيل الدخول إلى جهاز الكمبيوتر كمستخدم عادي وتشغيل قذائف مرتفعة. إذا تم إصدار Windows Terminal كما هو ، فلن يكون مفيدًا بالنسبة لي.

نقطة جيدة جدا. هذا القيد غير موجود مع إصدارات خاصة (غير متعلقة بالمتجر) من Windows Terminal.

بغض النظر عن "علامات التبويب المختلطة" ، أريد فقط أن أوضح ، لا يمكنك فعل ذلك مع (المعاينة التي تم إصدارها) Windows Terminal نظرًا لتصميم تطبيقات Windows Store. يمكنك فقط تشغيل المستخدم الذي ثبَّت هذا التطبيق وسجل دخوله باعتبارك ذلك المستخدم نفسه.

كل ما أريده هو أن أكون قادرًا على القيام بما أفعله اليوم ، وتسجيل الدخول إلى جهاز الكمبيوتر كمستخدم عادي وتشغيل قذائف مرتفعة. إذا تم إصدار Windows Terminal كما هو ، فلن يكون مفيدًا بالنسبة لي.

لقد فتحت للتو مثيلين من إنشاء متجر Windows Terminal - أحدهما مرتفع والآخر لا. لذلك لا أعرف لماذا لا يعمل من أجلك.

حسنًا ، يجب أن أصدق أنك مسؤول محلي على جهاز الكمبيوتر الخاص بك. لأكون واضحا ، ربما ينبغي علي التوضيح. أنا لست مسؤولًا محليًا أبدًا على محطة العمل الخاصة بي. لذلك عندما أذهب إلى "التشغيل كمسؤول" ، تتم مطالبتك بإدخال المستخدم / كلمة المرور.

يختلف حساب "المسؤول" الذي أستخدمه عن حساب قراءة البرامج الضارة / البريد الإلكتروني العادي. لذا فإن ما أفعله تقنيًا هو التشغيل كمستخدم مختلف. هذا هو قيود تطبيق متجر Windows. الحل (وربما سيفعلون ذلك) هو تحرير هذا كمكون Windows لا يحتوي على هذه القيود.

* [عاجل] كل ما وجدته حلاً لهذه المشكلة! * *

باتباع هذا الدليل
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
يمكنك جعل مجلد تطبيق windows خاصًا بك!

بمجرد القيام بذلك ، يمكنك تحديد موقع مجلد Microsoft.WindowsTerminal._blahblahYourVersion_ . بمجرد الدخول ، حدد موقع WindowsTerminal.exe الموضح أدناه

بمجرد العثور عليه ، قم بإنشاء اختصار لهذا الملف وضعه في أي مكان تريده. بعد القيام بذلك ، قم بتعيينه ليتم تشغيله كمسؤول. يمكنك القيام بذلك عن طريق النقر بزر الماوس الأيمن والانتقال إلى _ خصائص> خيارات متقدمة> تشغيل كمسؤول_ بعد ذلك انقر فوق "موافق" وستكون جاهزًا!

أنا شخصياً كنت بحاجة إلى هذا لأنني أستخدم الاختصار في شريط المهام الخاص بي حتى أتمكن من الضغط على _Windows + 1_ لتشغيله كمسؤول. ليست الطريق الطويل للتنقل عبر قائمة البداية الخاصة بي لتشغيلها بشكل صحيح.

يمكنك أيضًا فك ضغط الحزمة التي وضعناها في صفحة الإصدارات. إنه مجرد ملف مضغوط. يرجى ملاحظة أننا _ لا ندعم رسميًا_ التنفيذ غير المضغوط!

لكن هذا لا يزال يعني أنه لا توجد طريقة _ مدعومة_ للتشغيل بشكل مرتفع! أعتقد أن هذه ميزة لا بد منها.

في الواقع ، أنا أقف مصححًا.

ما _is_ مفقود هو إدخال "التشغيل كمسؤول" في قائمة النقر بزر الماوس الأيمن في اختصار شريط المهام.

تحدثت إلى عدد قليل من الأشخاص أمس في لقاء ، وقال عدد قليل من الأشخاص إنهم يطلقون بشكل أساسي powerhell باستخدام Windows + X ويودون أن يكون لديهم Terminal / Terminal كمسؤول هناك.

نقطة جيدة جدا!

هذا بالضبط وجهة نظري! هذا هو الحل لتشغيله من شريط المهام
بامتيازات المسؤول!

يوم الأحد 25 أغسطس 2019 الساعة 1:08 صباحًا Stéphane BARIZIEN [email protected]
كتب:

نقطة جيدة جدا!

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/terminal/issues/632؟email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW24
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

في الواقع ، أنا أقف مصححًا.

ما _is_ مفقود هو إدخال "التشغيل كمسؤول" في قائمة النقر بزر الماوس الأيمن في اختصار شريط المهام.

في شريط المهام ، انقر بزر الماوس الأيمن مرتين. مرة واحدة على الأيقونة لجعل قائمة السياق تظهر ، ثم مرة ثانية على اسم التطبيق. على سبيل المثال ، "Windows Terminal (Preview)" واختر "Run as Administrator"

أنا في حيرة.

إحمرار الوجه خجلا.

خجلان.

كيف لم أفكر في هذا؟

شكرا على أي حال لمشاركتنا جميعا!

لنلق نظرة على المشكلة من الطرف الآخر ...
يسمح Windows للعمليات غير المرتفعة بالتحكم في العمليات الأخرى غير المرتفعة ، وإرسال ضغطات المفاتيح ، والتقاط واجهة المستخدم الخاصة بهم ، وما إلى ذلك ... ولكنه يمنع العملية غير المرتفعة من القيام بذلك إلى نافذة عملية مرتفعة.
تم تصميم Windows Terminal ليتم استخدامه أيضًا لإدارة الخوادم البعيدة ، من خلال ssh ، واتصال PowerShell عن بُعد ، وما إلى ذلك ...
هذا يعني أن Windows Terminal يصبح ثغرة أمنية بمجرد استخدامه للإدارة ، حيث يمكن أن ينتظر برنامج ضار محلي جلسة Windows Terminal للتجسس على ما يفعله المستخدم ، وبمجرد اكتشافه لصدفة بعيدة ، حاول ذلك إدخال أوامر لإصابة الخادم باستخدام حقوق المسؤول.

لا يبدو منع Windows Terminal من العمل كمسؤول بمثابة تحسين أمني على الإطلاق ، لأن تشغيله كمسؤول سيحمي المستخدم بدلاً من ذلك من العمليات غير المتطورة التي تختطف جلسات shell البعيدة. يجب أن يوصى بتشغيله كمسؤول للمستخدم متى استخدم أداة تمنحه موجه أوامر مرتفعًا ، محليًا أو عن بُعد.

وحول sudo لنظام التشغيل Windows ، ألا يؤدي تشغيل خدمة sshd ثم الاتصال بالمضيف المحلي من قشرة غير مرتفعة إلى ظهور نفس مشكلة الأمان؟

هذا يعني أن Windows Terminal يصبح ثغرة أمنية بمجرد استخدامه للإدارة ، حيث يمكن أن ينتظر برنامج ضار محلي جلسة Windows Terminal للتجسس على ما يفعله المستخدم ، وبمجرد اكتشافه لصدفة بعيدة ، حاول ذلك إدخال أوامر لإصابة الخادم باستخدام حقوق المسؤول.

في حين أنه من الصحيح أن النظام البعيد يمكن أن يكون مصابًا (على افتراض أن العملية البعيدة لها حقوق المسؤول) ، فإن هذا لا يعني أنه يجب علينا أيضًا السماح لها بإصابة النظام المحلي أيضًا.

لا يبدو منع Windows Terminal من العمل كمسؤول بمثابة تحسين أمني على الإطلاق ، لأن تشغيله كمسؤول سيحمي المستخدم بدلاً من ذلك من العمليات غير المتطورة التي تختطف جلسات shell البعيدة. يجب أن يوصى بتشغيله كمسؤول للمستخدم متى استخدم أداة تمنحه موجه أوامر مرتفعًا ، محليًا أو عن بُعد.

لا شيء يمنعك من تشغيل Windows Terminal بحقوق المسؤول الآن. تتعلق المشكلة المطروحة حاليًا بوجود مختلط بين علامات تبويب مرتفعة وغير مرتفعة.

SamuelEnglard بقعة على الاستجابة.

للإضافة ، ما نحاول القيام به هو تجنب إضافة ثغرات أمنية جديدة. كانت وحدة التحكم الأصلية هي نفس المشاكل الواردة في إدارة الخادم البعيد. لا شيء يمكننا القيام به حيال ذلك للأسف. دائمًا ما يقوم المستخدمون الذين يقومون بإدارة الخادم عن بُعد بتشغيل وحدات التحكم / المحطات الطرفية الخاصة بهم بشكل مرتفع ، وهذا سيمنحهم بعض الأمان الإضافي (على الرغم من أنني لست خبيرًا أمنيًا ولن أفسر هذا البيان على أنه نصيحة)

فكرة للتقدم في هذه المشكلة: حاول تشغيل التطبيق _app_ بالكامل على أنه مرتفع ، وإذا نجح ذلك ، أضف زرًا بجوار كل زر "فتح" مع رمز درع UAC ، وأضف رابط مفتاح بادئة لفتح علامة تبويب مرتفعة: السيطرة على التحول هـ . (لقد تحققت وكان هذا غير منضم.) إنه يعمل فقط مع علامة التبويب التالية المفتوحة.

على أي حال ، تحتوي علامات التبويب المفتوحة على رمز UAC قبل أيقونتها العادية ، ويتم تشغيلها كمسؤول. (تذكر أن البرامج لا يمكنها إرسال هذه المفاتيح بعد الآن. لقد قمنا بتشغيل التطبيق كمسؤول.)

يجب أن يحاول التطبيق رفع المستوى تلقائيًا ، وإذا فشل ذلك ، فقم بالتشغيل بشكل طبيعي وتجاهل سلسلة المحادثات هذه بالكامل.

في الواقع ، أنا أقف مصححًا.
ما _is_ مفقود هو إدخال "التشغيل كمسؤول" في قائمة النقر بزر الماوس الأيمن في اختصار شريط المهام.

في شريط المهام ، انقر بزر الماوس الأيمن مرتين. مرة واحدة على الأيقونة لجعل قائمة السياق تظهر ، ثم مرة ثانية على اسم التطبيق. على سبيل المثال ، "Windows Terminal (Preview)" واختر "Run as Administrator"

لاحظت للتو أن موجه UAC الذي يحصل عليه الشخص في هذه الحالة يقول "برنامج غير معروف".

غير متوقع إلى حد ما إذا سألتني ...

@ sba923 هذا # 2289: ابتسم:

@ DHowett-MSFT شكرا على المعلومات ؛ من الجيد معرفة أنه تم تتبعه (بالفعل).

أفضل إجابة لهذا يمكن أن أفكر فيها هي أن يكون لديك خيار الحصول على ملف تعريف يجب أن يكون مرتفعًا وإذا لم تكن النوافذ الحالية مرتفعة ، فابدأ بمثيل مرتفع جديد باستخدام هذا الملف الشخصي. (فكر في كيفية عمل جلسات التصفح الخاصة)

فكرة جيدة جدا

لقد استخدمت هذه الطريقة لإضافة Terminal في قائمة Win + X:
قم بإنشاء اختصار جديد باستخدام الهدف:
C: \ Windows \ explorer.exe shell: appsFolder \ Microsoft.WindowsTerminal_xxxxxxxxxxxx! التطبيق
تعديل:
عذرًا ، لن يعمل هذا إذا كنت تريد تشغيل التطبيق كمسؤول.
بدلاً من ذلك ، يمكنك استخدام nircmd وإنشاء اختصار باستخدام
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(يمكن معرفة المسار الصحيح لـ "Microsoft.WindowsTerminal_xxxxxxxxxxxx" باستخدام أمر PS "Get-appxpackage * WindowsTerminal *" ، استخدم الإدخال في PackageFamilyName)

يمكن استخدام هذا الاختصار لبدء تشغيل الجهاز بامتيازات المسؤول بنقرة مزدوجة بسيطة وباستخدام WinXEditor ، يمكن إضافته في قائمة Win + X.
ملاحظة: يجب أيضًا تثبيت الجهاز في حساب المسؤول.

هل فكرة تحميل كل ملف تعريف كمسؤول أم ملفات معينة فقط؟ من الناحية المثالية ، أود الحصول عليها من خلال ملف شخصي فردي. ربما الخاصية التي هي حساب "روناس" وآخر باسم "iselevated"؟

كما تمت مناقشته بإسهاب في هذا الموضوع ، لا يمكنك الحصول على مزيج من المرتفعات وغير المرتفعة في نفس مثيل Windows Terminal ، ولن تتم إضافة هذا.

في الواقع ، أنا أقف مصححًا.
ما _is_ مفقود هو إدخال "التشغيل كمسؤول" في قائمة النقر بزر الماوس الأيمن في اختصار شريط المهام.

في شريط المهام ، انقر بزر الماوس الأيمن مرتين. مرة واحدة على الأيقونة لجعل قائمة السياق تظهر ، ثم مرة ثانية على اسم التطبيق. على سبيل المثال ، "Windows Terminal (Preview)" واختر "Run as Administrator"

FWIW ، لقد قمت للتو باختبار التحول والنقر بزر الماوس الأيمن والذي يعطي خيار "التشغيل كمسؤول" على الفور - فقط أسرع قليلاً من خيار النقرتين اليمنى اللذين كانا في السابق خيار الانتقال.

مرحبًا يا رفاق ، هل نسيت UAC؟ لا يمكن للتطبيق النقر فوق الأشياء الموجودة في سطح المكتب الآمن.

FWIW ، لقد قمت للتو باختبار التحول والنقر بزر الماوس الأيمن والذي يعطي خيار "التشغيل كمسؤول" على الفور - فقط أسرع قليلاً من خيار النقرتين اليمنى اللذين كانا في السابق خيار الانتقال.

يمكنك أيضًا ctrl + shift + النقر بزر الماوس الأيسر على الرمز لإحضار UAC على الفور.

رائع ، شكرا حفنة! كم عدد الاختصارات التي يجب أن نتذكرها؟ ؛-)

إلى النقطة الرئيسية الخاصة بك حول "تشغيل كمستخدم مختلف" غير موجود / لا يعمل: هذا أحد قيود النظام الأساسي الذي نحاول رفعه. ليس من خلال الحقد أو عدم الكفاءة أننا لا ندعمها.

بالنسبة لسبب دعم تطبيقات وحدة التحكم الأخرى _do_ ، فهي ليست آمنة عندما تفعل ذلك لأنها لا تستضيف على وجه التحديد مستويات ارتفاع مختلفة في نفس النافذة. هذه هي القضية الأساسية هنا. نظرًا لاستضافتها في عمليات قائمة بذاتها بنوافذ مستقلة ، فهي خالية من القيود المفروضة على التلاعب عبر مستوى التكامل.

بالتأكيد آمل أن يكون الجري كمستخدم مختلف شيئًا يأتي في مرحلة ما. على الرغم من أن معظم نشاطي اليومي ليس غالبية أنشطتي اليومية ، إلا أن بعض أوامر cmdlets من بوويرشيل تتطلب ارتفاعًا (وأنا أعمل مع مستخدمين مختلفين ، أعتقد أن مسؤول المستخدم المحمي).

إنها ليست نهاية العالم ، ولكن سيكون من المزعج بالتأكيد الاضطرار إلى العودة إلى القذائف القديمة.

في الوقت المناسب ، على ما أظن!

لا توجد مشكلة / قيود على الإطلاق في استخدام Windows Terminal المرتفع ، لذلك لا داعي للالتزام بـ "الصدفة القديمة" (أو لنكون أكثر دقة: مضيف وحدة التحكم القديمة).

كل ما في الأمر أنه لا يمكنك المزج بين مرتفعة وغير مرتفعة في (علامات تبويب مختلفة داخل) نفس الحالة .

لا توجد مشكلة / قيود على الإطلاق في استخدام Windows Terminal المرتفع ، لذلك لا داعي للالتزام بـ "الصدفة القديمة" (أو لنكون أكثر دقة: مضيف وحدة التحكم القديمة).

كل ما في الأمر أنه لا يمكنك المزج بين مرتفعة وغير مرتفعة في (علامات تبويب مختلفة داخل) نفس الحالة .

أعتقد أنني ربما أساءت تفسير ما ورد أعلاه ، ولكن هناك قيود على النظام الأساسي لتشغيل الجهاز ضمن سياق مستخدم مختلف تمامًا عما أقرأه.

أعتقد أنني ربما أساءت تفسير ما ورد أعلاه ، ولكن هناك قيود على النظام الأساسي لتشغيل الجهاز ضمن سياق مستخدم مختلف تمامًا عما أقرأه.

يا ، هذا الخيط كان منتشرًا في كل مكان حول تلك النقطة. أنا لست مسؤولاً في محطات العمل الخاصة بي ، لذا فإن "التشغيل كمسؤول" يطالبني فقط بإدخال "اعتماداتي المرتفعة".

ربما يجب أن يكون لدينا ببساطة موضوع جديد حول حالة الاستخدام هذه.

لكي أكون واضحًا ، ما أعنيه (وأعتقد أن الكثير من حاجة "المسؤولين") هو القدرة على تسجيل الدخول إلى محطة العمل الخاصة بنا كمستخدم عادي. ثم قم بتشغيل "بعض shell" كمستخدم مرتفع كما هو الحال في إدارة المجال للقيام بعمل AD.

صواب أو خطأ ، هذا ما يفعله ويحتاجه البعض منا. كل الحيل المتعلقة بتثبيت وحدة التحكم من المتجر لأن هذا المستخدم وابتكار اختصارات ذكية لم تنجح حقًا بالنسبة لي.

ونعم ، يمكنني القيام بذلك بعدة طرق وربما ينبغي أن أقصر بعض هذه الأنشطة على محطة عمل محمية ولكن الواقع ، كمستخدم عادي ، لست بحاجة إلى غلاف بشكل عام.

ينبع الارتباك في IMVHO من حقيقة أن الناس (يحتفظون بعادات ما قبل فيستا تموت بشدة) بشكل متبادل باستخدام المصطلحين "مرتفع" و "كمستخدم [مجال] [مشرف] آخر."

إن التشغيل كمستخدم آخر ليس هو نفس الشيء مثل الجري في وضع مرتفع.

1. يحتاج بعض الأشخاص الموجودين في هذا الموضوع ، عند تسجيل الدخول كمستخدم مسؤول ، إلى تشغيل أحمال عمل Windows Terminal مع الارتفاع.

2. يحتاج بعض الأشخاص الآخرين ، عند تسجيل الدخول كمستخدم عادي (أو غير مسؤول المجال) ، إلى تشغيل أحمال عمل Windows Terminal كمستخدم إداري آخر ، وعادة ما يكون مع ارتفاع.

3. يمكن للمرء أيضًا النظر في الحالة التي يتم فيها تسجيل دخول الأشخاص كمستخدم عادي A ويريدون تشغيل أحمال عمل Windows Terminal كمستخدم B بدون ارتفاع.

في # 2 و # 3 ، يجعل النشر المستند إلى متجر Windows القصة أكثر تعقيدًا ، لأن Windows Terminal لن تعمل كمستخدم مسجل الدخول ، حيث يتم نشر "تطبيقات المتجر" لهذا المستخدم.

آمل أن أفهم الموقف بشكل صحيح. إذا فعلت ذلك ، آمل أن يوضح هذا الأمر قليلاً.

لقد فهمت ذلك بالضبط.

فقط لمعلوماتك ، هذه المشكلة بالضبط ، غير قادر على رفع مستوى ("تشغيل كمسؤول" ، بدلاً من التشغيل كمستخدم إداري آخر ، "تشغيل كمستخدم مختلف") عندما يكون الحساب الذي قمت بتسجيل الدخول به ليس مسؤولاً محليًا على النظام ، وفقًا لأفضل الممارسات) ، تمت تغطيته بإيجاز في مشكلة أخرى: https://github.com/microsoft/terminal/issues/1538 . تم إغلاق ذلك بشرح أنها مشكلة Windows ، وليست مشكلة طرفية ، حيث يبدو أنها قيود على تطبيقات المتجر.

بدون الدخول في نقاش حول ما إذا كان يجب إصدار هذا كتثبيت MSI بدلاً من استخدام المتجر ، هناك حل بديل في هذا الموضوع الذي استخدمته ؛ قم بتسجيل الدخول لفترة وجيزة كحساب المسؤول الخاص بك ، وقم بتثبيت التطبيق من المتجر ، ثم قم بتسجيل الخروج مرة أخرى. تشغيل كمسؤول ثم عمل لحساب المستخدم العادي الخاص بي (حتى التحديث التالي ، عندما يتعين القيام بذلك مرة أخرى).

نعم ، يجب أن يكون هناك MSI متاحًا. لا يسمح صاحب العمل الجديد بتثبيتات المتجر (العام) ، لذا فإن الطريقة الوحيدة التي سأتمكن من خلالها من استخدام Windows Terminal هي البناء من المصدر ...

بخيبة أمل لرؤية أنه لا يمكنك تشغيل Windows Terminal "كمسؤول" دون أخطاء ثم الاضطرار إلى تنفيذ حل بديل. أود أن أقول إن الكثير من الشركات تطبق نهج فصل الامتيازات للهويات (مع امتلاك موظفي تكنولوجيا المعلومات والاتصالات حسابًا مميزًا وغير مميز). لذا ، فإن القدرة على استيعاب هذا المطلب من خلال توفير نشر MSI اختياري وفقًا لاقتراح @ sba923 سيكون أسلوبًا أنيقًا إلى أن تتمكن التطبيقات المجمعة المخزنة في هذا الوقت من التعامل مع فصل الامتيازات؟

هذه معاينة ولا حتى إصدار 1.0 ...

أشعر أن هذا الموضوع قد تمت مناقشته جيدًا إلى حد ما في هذه المرحلة ، ولكن هناك منظور واحد لم أفهمه بعد: لماذا لا يمكننا إنشاء اختصار Windows لهذا التطبيق؟ هذا هو الحل المعتاد لـ "التشغيل دائمًا كمسؤول" - الحل المعتاد هو إنشاء اختصار وتغيير الاختصار لاستخدام الوصول المرتفع كإعداد افتراضي.

هل يمكن لأي شخص أن يشرح لي لماذا لا يمكننا إنشاء اختصار لهذا التطبيق؟ ربما يكون هذا أكثر ارتباطًا بالأعمال الداخلية لنظام Windows أكثر من الأعمال الداخلية لـ Terminal ، لكنني أشعر أننا نتغلب على الأدغال إذا لم أطلب ذلك مباشرة.

شكرا.

احتفظ بـ 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 Terminal. إنه حل لائق في الوقت الحالي.

سأكون على ما يرام مع القدرة على تمييز الجلسات على أنها مرتفعة وفتحها في نافذة جديدة ، بصراحة.

لقد جئت إلى هنا بحثًا عن حل أنيق ولكن لا يبدو أنه موجود ، لذا سأشارك حل الاختراق الخاص بي. أضفت ملفًا شخصيًا لتشغيل powerhell مرفوعًا:

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

تنبثق في نافذة منفصلة لكنها تنجز العمل.

أشعر أن هذا الموضوع قد تمت مناقشته جيدًا إلى حد ما في هذه المرحلة ، ولكن هناك منظور واحد لم أفهمه بعد: لماذا لا يمكننا إنشاء اختصار Windows لهذا التطبيق؟ هذا هو الحل المعتاد لـ "التشغيل دائمًا كمسؤول" - الحل المعتاد هو إنشاء اختصار وتغيير الاختصار لاستخدام الوصول المرتفع كإعداد افتراضي.

هل يمكن لأي شخص أن يشرح لي لماذا لا يمكننا إنشاء اختصار لهذا التطبيق؟ ربما يكون هذا أكثر ارتباطًا بالأعمال الداخلية لنظام Windows أكثر من الأعمال الداخلية لـ Terminal ، لكنني أشعر أننا نتغلب على الأدغال إذا لم أطلب ذلك مباشرة.

شكرا.

aaronsteers ، أنت محق في أن الأمر يتعلق بنظام Windows أكثر منه حول Terminal. المشكلة الرئيسية هنا هي أننا تم توزيعنا وتثبيته كـ "حزمة تطبيقات حديثة". لديهم عدد من القيود والقيود العرضية مقارنة بالتطبيقات الأصلية ، ولكنه ضروري للوحدة الطرفية لأنها أيضًا الطريقة الأقل صعوبة لاستخدام مكونات "واجهة برمجة تطبيقات Windows الحديثة" (WinRT). إنه أمر محبط للغاية لجميع أعضاء الفريق طوال الوقت تقريبًا. :ابتسامة:

نحاول تحويل هذا الإحباط وإحباط المجتمع إلى تقدم للمنصة. سأعتذر ، مع ذلك ، هذا التغيير ليس سريعًا هنا في Windows!

DHowett أحاول حقًا أن أفهم ، لأنني أحب 2/3 Terminal ، لكنها لا تقوم ببعض الأساسيات التي اعتدت عليها مع TakeCommand أو ConEmu ، إلخ.

لا يمكنني المزج بين الارتفاعات في علامات التبويب المختلفة. إذا كنت أفهم ذلك ، فذلك لأنك نوع مختلف من التطبيقات ولا تستضيف الصدفة حقًا؟

لا يتم مسح المخزن المؤقت للتمرير للخلف ، في أي من البيئات الثلاث (cmd ، PowerShell ، wsl bash.) إنه يحدث في الأصداف العادية. مرة أخرى ، بسبب كيفية استضافته؟

وسيكون من الجيد جدًا أن يكون لديك سياق أو قائمة منسدلة يسهل الوصول إليها. على سبيل المثال ، لمسح هذا التمرير للخلف ، مع الأخذ في الاعتبار أن خدعة الهروب من وحدة التحكم لم تنجح معي.

إن تكامل البيئات ومدى التقاطها لقذائف WSL Linux أمر رائع حقًا. لكنها تكلف الكثير من سهولة الاستخدام من خلال مشكلات الارتفاع والتمرير للخلف ، لذلك نادرًا ما أستخدمها.

robomac هناك منشور رائع بواسطة @ DHowett-MSFT هنا يشرح سبب عدم قدرتنا على مزج علامات التبويب المرتفعة وغير المرفوعة في نفس النافذة التي لم يتم رفعها.

tl ؛ dr هو: إذا سمحنا للمستخدمين بالاتصال بأسطر أوامر مرتفعة من نافذة طرفية غير مرفوعة ، فإن ذلك يخلق فجوة أمان عملاقة ، حيث يمكن للتطبيقات الأخرى التي لم يتم رفعها دفع العملية المرتفعة بشكل فعال ، عبر نافذة Terminal.

لا أعرف كيف يخفف ConEmu من هذه المخاطر ، إذا فعلوا ذلك على الإطلاق. من المحتمل تمامًا أن يكون هذا هو الثقب الأمني ​​الذي أحدثه conemu والذي لا نريح الشحن كجزء من Windows Terminal.

بقية مخاوفك هي جميع المشكلات التي يتم تتبعها في مكان آخر في هذا الريبو ، أقترح البحث عنها لتتبع التقدم المحرز بشكل فردي. نفضل الاحتفاظ بهذا الموضوع في الموضوع الفردي "ارتفاع علامات التبويب المختلط" / "وجود ملف تعريف يتم إطلاقه بشكل مرتفع"

حول الموضوع: أريد تجربة المسار "بدء تشغيل مثيل آخر مرتفع" للملفات الشخصية "المرتفعة". إذا لم تكن تجربة المستخدم سيئة للغاية ، فهذا طريق محتمل للمضي قدمًا هنا ، على الأقل كخيار.

ConEmu لا يخفف من هذه المخاطر. إنهم ينقلون هذا الخطر إلى مستخدميهم. (لست متأكدًا من أنهم يوثقون هذا الخطر.)

في موضوع "تشغيل مثيل آخر مرتفع": لا أمانع في هذا السلوك طالما أنه يمكنه استخدام نفس المثيل المرتفع من Terminal لعلامات التبويب هذه وعدم تشغيل مثيل جديد في كل مرة أقوم باستدعاء ملف تعريف "مرتفع".

في رأيي ، فإن "عملاقة" تلك الفجوة الأمنية مبالغ فيها بعض الشيء. ليس من الطبيعي أن يكون لديك برنامج ضار على جهاز الكمبيوتر الخاص بك يجلس وينتظر فرصة للارتقاء ، لذا فإن التضحية بالراحة من أجل الأمان لا يبدو صحيحًا.

من ناحية أخرى ، إذا كان الهدف النهائي هو أن يتم شحن WT مع Windows كمحطة افتراضية ، فإن ذلك سيزيد من سطح الهجوم بشكل كبير. لكن مرة أخرى ، في هذه الحالة ، سأخفف شخصيًا من المخاطر باستخدام بديل غير محبوب ومن غير المرجح أن يكون هدفًا لمثل هذا الهجوم ويوفر الراحة المطلوبة (بافتراض أن اكتشاف وجود علامة تبويب مرتفعة في الجهاز أمر غير مهم بدرجة كافية لتكون خاصة بالمحطة).

بعض من هذا هو TL ؛ بالنسبة لي ، ولكن إذا أخذت الحزمة وتفريغها ، يمكنك تشغيل الوزن خارج وضع الحماية ، مما يعني الارتفاع ، وتشغيله كمستخدم مختلف يعمل دون مشكلة. لقد تحدثت إلى MSFT عند الإشعال حول هذا الأمر وقيل لي أن أقدم طلب سحب ، لكن مهارات VS الخاصة بي ضعيفة جدًا. ما سيكون سهلاً بما يكفي للقيام به هو التوقيع بشكل صحيح (كان يجب أن أفعل ذلك باستخدام pki الداخلي الخاص بي حتى أتمكن من التشغيل على applocker) ووضعه في تنسيق MSI أو MSIX القابل للتوزيع. هناك خطأ غريب هنا أو هناك قد يكون محددًا لتشغيله بهذه الطريقة ولكنه بشكل عام يعمل بشكل جيد حقًا. في الوقت الحالي ، لدي فقط وظيفة لاستخراج وتوقيع واستبدال / تحديث إصدار يعتمد على ملفات البرنامج من الإصدار المستند إلى المتجر.

أنا أتفهم مخاطر هذه الميزة المتمثلة في "توصيل" علامات التبويب المرتفعة بعملية غير محسَّنة ، ولكن ألا يمكن المضي قدمًا في الاتجاه المعاكس؟
إدراكًا للناس كيف يحتاجون إلى ذلك ، دع المحطة نفسها تعمل أيضًا على أنها مرتفعة وتسمح ببدء علامات تبويب غير مرفوعة؟
بالطبع ، هذا له عيوب أخرى ، لكن بالنسبة لي (وأعتقد للآخرين أيضًا) فهي مقبولة.
(بالتأكيد ، قد يكون هذا "مثيرًا للاهتمام" لأن الجهاز هو تطبيق متجر Windows ، ولست متأكدًا مما إذا كان ذلك يعمل)

ملاحظة. نأسف لإعادة فتح هذه المشكلة (أيضًا إذا قدم شخص آخر هذا الاقتراح بالفعل و "قرأت" ذلك).

بفضل EmTschi ، صنعت حلًا بسيطًا ومريحًا بنسبة 100٪
يستخدم قائمة السياق ويعمل تمامًا مثل PowerShell 7
https://github.com/nt4f04uNd/wt-contextmenu
هناك يمكنك العثور على دليل حول كيفية تنفيذه وجميع الملفات المطلوبة

شكرًا على النصيحة ، سأحاول ذلك لاحقًا.
أعمل حاليًا مع اختصارين على سطح المكتب ، تم تعيينهما للمفاتيح Ctrl + Alt + T و Ctrl + Alt + Shift + T لمحطة مرتفعة ، لا بأس أيضًا كحل بديل ، ولكن ... ليس جيدًا كما يمكن أن تكون وعلى بعد أميال من شيء مثل سودو.

@

كلما حاولت تشغيل تطبيق Terminal باستخدام حساب مسؤول ، انقر بزر الماوس الأيمن -> تشغيل كمسؤول ، تنبثق UAC مرتين ويحدث خطأ يقول:
"يتعذر على Windows العثور على (المسار \ WindowsTerminal.exe) تأكد من كتابة ...".
المسار موجود ويعمل التطبيق بشكل صحيح للمستخدم غير المسؤول الذي أنشأ التطبيق ، لكن المستخدم المسؤول الآخر غير قادر على تشغيله.
إذا قمت بتسجيل الدخول إلى المستخدم المسؤول ، فلن يكون التطبيق الطرفي موجودًا في الإعدادات أو قائمة البدء ، كما لو لم يتم تثبيته مطلقًا على النظام.
هل هناك طريقة لإنشاء التطبيق بحيث يتم تثبيته لجميع المستخدمين؟ أم أن جذر المشروع يجب أن يكون في دليل غير مستخدم محدد؟

أرى نفس المشكلة تحدث أيضًا.

إصدار Windows 18922.1000

تم التثبيت للتو على تحديث Win10 1909 ، ولدي نفس المشكلة مع محاولة التشغيل كمسؤول

نفس المشكلة هنا. لا يمكن استخدام windows terminal الآن لأنني أحتاج دائمًا إلى تشغيل docker وبعد ذلك أحتاج دائمًا إلى أن أكون مشرفًا في الجهاز ...

لدي حل اختراق لمن يريده:

1. قم بتنزيل msixbundle من صفحة الإصدار
2. قم بفك ضغط ذلك ، هناك ، ابحث عن msix المخصص لمنصتك (عادةً x64 واحد)
3. قم بفك ضغط ذلك في مجلد في مكان ما
4. انسخ هذا المجلد أينما تريد وقم بتشغيل WindowsTerminal.exe برفع أو كيفما تشاء

يبدو أن الكثير من هذا الإخفاق يأتي من راحة امتلاك هذا كتطبيق متجر. هناك نقاش حول هذا الموضوع في # 1386 وقد ذكر أحدهم أنه ربما يتم التثبيت باستخدام Scoop ، والذي يقوم بأتمتة عملية الاستخراج المذكورة أعلاه.

سيكون من الجميل أن يتم التعامل مع من يلي كمواطنين من الدرجة الأولى:

1. عمليات التثبيت المحمولة (ملفات مضغوطة - حتى إذا لم يكن التهيئة محمولة بعد ، حيث إنها تعيش ضمن AppData \ Local عند نفاد منطقة تثبيت متجر Windows)
2. مُثبِّت exe. قديم عادي (أو .msi ، إذا لزم الأمر) للأشخاص الذين لا يريدون المتجر أو لاستخدام مثبت المتجر

كلاهما ليسا صعب التنفيذ من إجراء البناء الحالي ، كما يتضح من أتمتة Scoop. والآن بعد أن أصبح Windows Terminal أصبح Really Rather Good ، أود أن أكون قادرًا على استخدامه مثل أي محطة أخرى.

أثناء وجودنا فيه: ما لم يكن هناك عدم توافق مع واجهة برمجة التطبيقات ، سيكون من الرائع أن يكون لديك خيار تثبيت Windows Terminal بدون المتجر (حتى الطريقة "المحمولة") على الإصدارات السابقة من Windows 10 (صاحب العمل يحظرنا عند 1809 / RS5 ، والتثبيت من المتجر محظور).

@ sba923 إذا لم نعتمد على واجهات برمجة التطبيقات الموجودة فقط في عام 1903 ، فلن نطلب 1903.

بالتأكيد ... كان تخميني 😜

سوف تضطر إلى الضغط من أجل الترقية على مستوى الشركة ، ومن المحتمل أن تصطدم بالحائط ...

هذا في منتهى الغباء.

لنقم بإنشاء محطة طرفية موحدة جديدة لموجه الأوامر ، وبوويرشيل ، وباش للنوافذ.
هل يمكنني تشغيل cmd.exe كمسؤول؟
رقم.

أعتقد أنني سأحتفظ برموز cmd.exe ورموز بوويرشيل الخاصة بي مسبقًا للعمل كمسؤول على شريط المهام الخاص بي إلى أجل غير مسمى بعد ذلك.

أشياء غبية كهذه هي السبب في أن آلة عملي الرئيسية لا تزال Macbook.

هذا في منتهى الغباء.

لنقم بإنشاء محطة طرفية موحدة جديدة لموجه الأوامر ، وبوويرشيل ، وباش للنوافذ.
هل يمكنني تشغيل cmd.exe كمسؤول؟
رقم.

أعتقد أنني سأحتفظ برموز cmd.exe ورموز بوويرشيل الخاصة بي مسبقًا للعمل كمسؤول على شريط المهام الخاص بي إلى أجل غير مسمى بعد ذلك.

أشياء غبية كهذه هي السبب في أن آلة عملي الرئيسية لا تزال Macbook.

أوافق في هذه الحالة. أريد نافذة Windows Terminal واحدة تضم جميع علامات تبويب المحطة الطرفية التي أحتاجها ، حيث يمكن أن تكون كل علامة تبويب طرفية واحدة من عدة مضيفات طرفية مثبتة ، وتكون مرتفعة أم لا.

يبدو حقًا أن ميزة الارتفاع المختلطة هذه تتراجع بسبب قرار التصميم الفني لاستضافة جميع علامات التبويب على مقبض HWND واحد.

1) هل يمكنك تشغيل المحطة الجديدة كمسؤول؟ نعم (توجد مشكلات في القيام بذلك اعتمادًا على كيفية تثبيته / تشغيله ولكن لا توجد رغبة في عدم نجاح ذلك). (إذا كنت لا تعرف كيفية القيام بذلك ، فراجع المنشورات المتعددة أعلاه حول كيفية القيام بذلك.

2) هل يمكن أن يكون لديك علامة تبويب مرتفعة بينما الأخرى ليست كذلك؟ لا . راجع https://github.com/microsoft/terminal/issues/632#issuecomment -519375707 لمعرفة السبب.

هل يمكن للأشخاص تذكر أن هذه المشكلة تتعلق بعلامات تبويب ارتفاع مختلطة؟!؟ إذا كنت ترغب في بدء تشغيل العملية برمتها بشكل كبير ولا يمكنك فتح مشكلة جديدة.

@ DHowett-MSFT هل يمكننا إعادة تسمية هذه المشكلة لتكون حول علامات تبويب ارتفاع مختلطة؟

مهما كانت الطريقة التي يتم بها التعامل مع هذا أم لا ، يجب أن تحتوي المحطات أو علامات التبويب المرتفعة على نوع من المؤشرات. الآن إذا بدأت محطة جديدة مع تشغيل كمسؤول ، فلا توجد طريقة لملاحظة بسهولة أن علامات تبويب cmd الخاصة بي تتمتع بوصول مرتفع مقارنة بتلك الموجودة في النافذة التالية.

تحرير بعد تعليق SamuelEnglard : من الواضح أنني اخترت على عجل cmd كمثال سيء. نعم ، يظهر cmd "المسؤول:" في عنوان علامة التبويب. لكن WSL Ubuntu bash في علامة التبويب الافتراضية الخاصة بي يحل محل كل ما قد يكون موجودًا في عنوان علامة التبويب. أعتقد أن bash لا يعرف (أو حتى يهتم) بارتفاع Windows Terminal ، لذلك لا يمكن استخدام هذه المعلومات عند تحديث العنوان من داخل bash (هناك بالطبع sudo الوضع ، لكن هذا شيء مختلف).

في Terminal profiles.json ، هناك
"showTabsInTitlebar": false
ولكن مع هذا الإعداد ، لا يشير شريط عنوان المحطة الطرفية إلى الارتفاع.

janilahti تفعل علامات تبويب CMD المرتفعة لا تشبه
لك؟

الأمان هو نقطة خلافية إذا لم يرغب أحد في استخدام أداتك ...

يجب على Ya'll فقط إصدار أمر sudo للنوافذ التي تعمل في كل من cmd.exe و powerhell. سيوفر ذلك لي مشكلة وجود اختصار لكليهما للتشغيل كمسؤول.

لمعلوماتك ، كتبت sudo for windows ، يُدعى gsudo : https://github.com/gerardog/gsudo

وهو يدعم رفع أوامر cmd / powershell / pwsh أو الغلاف بالكامل. إنه سهل التثبيت والاستخدام ويجب أن يشبه * nix sudo الأصلي. هناك تطبيقات أخرى sudo في البرية لكن IMHO ، gsudo هي الأكثر تنوعًا وسهولة في الاستخدام.

يمكنك استخدامه ، على سبيل المثال ، لإنشاء ملف تعريف WT يستدعي gsudo cmd / gsudo pwsh أو gsudo WhateverShell لإطلاق علامات تبويب مرتفعة. قم بتثبيت gsudo وأضف ملف تعريف WT:

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

إنه تطبيق خادم عميل C # يعمل كعميل عندما لا يكون مرتفعًا ، ويطلق نفسه كخادم. كلتا الحالتين تتواصل عبر أنابيب مسماة مؤمنة. تشبه برامج windows sudos الأخرى في البرية في الغالب البرامج النصية لـ PowerShell 'runas' التي تنبثق نافذة جديدة ، ولكن كونه تطبيقًا كاملاً سمح لي بإضافة المزيد من الميزات.

لقد قرأت الخيط وتمت مناقشة أمان أمر sudo وتم وضع بعض النقاط الصحيحة. لقد اتخذت جميع الإجراءات الأمنية التي يمكنني التفكير فيها وأنا منفتح (وأخطط) لتقديم المزيد منها. في هذه المرحلة ، يجب أن يكون آمنًا / غير آمن كما لو كنت تفتح جلسة PS للمشرف عن بُعد أو إذا قمت بإجراء ssh root@server من وحدة تحكم غير مرتفعة. (على سبيل المثال ، عرضة لضربات المفاتيح أو تخريد الشاشة ، وصححني إذا كنت مخطئًا ولكن ما أفهمه هو أن * nix sudo عرضة للخطر أيضًا بهذه الطريقة). هناك أيضًا ذاكرة التخزين المؤقت لبيانات الاعتماد ، والتي تقلل مقدار النوافذ المنبثقة لحسابات المستخدم أثناء جلسة مدتها 5 دقائق (مستوحاة من * nix sudo) ، والتي من الواضح أنها ناقل للهجوم ، يمكن تعطيلها عبر config. بالنسبة لأولئك القلقين بشأن الأمان ، أخطط لإضافة طريقة سهلة للغاية لتشديده (عن طريق تعطيل ميزات مثل ذاكرة التخزين المؤقت لبيانات الاعتماد) بأمر بسيط أو عبر إعداد سياسة / تسجيل مجموعة المؤسسة.

إحدى النقاط المثيرة للاهتمام التي تم توضيحها في هذا التعليق هي أن Microsoft لا تستطيع تحمل "قبول المخاطرة لراحة المستخدم". إذا كانت هذه هي الكلمة الأخيرة من MS ، فعندئذ يبدو هذا على الأقل كحل بديل لائق (كامل الوظائف) ، ويتم الترحيب بجميع التعليقات / المشكلات أو الأفكار المتعلقة بكيفية تحسين الأمان.

لا يمكن أن يكون شيئًا يجب أن أقوم بتثبيته غير مدعوم رسميًا. يقتل أي قدرة على استخدامه في بيئة الشركة.

ثم hparadiz ، سيتعين عليك الانتظار حتى يتم إصدار إصدار جديد من النوافذ بتصميم أمان جديد يسمح باستخدام sudo الرسمي (أو علامات تبويب الارتفاعات المختلطة) دون مخاطر أمنية. يبدو أنه لن يحدث قريبًا. أفضل لقطة لك هي الانتظار حتى يمكن إطلاق WT بالكامل كمسؤول ، يتم تعقبه في # 4217 ، ومن المحتمل أن يتم إصداره قريبًا.

تم العثور على اختراق رائع من مدونة:

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

gerardog هل لديك دلو مغرفة مقابل gsudo ؟ أم هو في واحد معروف؟ أنا حاليًا على صندوق لينوكس ، لذا لا يمكنني التحقق.

fluffynuts إنه موجود في الريبو الرئيسي في سكوب. لذلك فقط "سكوب تثبيت gsudo". يتم أيضًا سرد طرق التثبيت الأخرى في https://github.com/gerardog/gsudo . لكن دعنا نحافظ على هذه المناقشة حول موضوع WT. 😉

سؤال مفتوح: إذا كان خلط علامات التبويب المرتفعة وغير المرتفعة يمثل خطرًا أمنيًا ، فهل هذا الخطر موجود في ConEmu ؟ لأنه يمكن أن يفعل ذلك بالضبط. أم أن ConEmu تنفذ هذه الميزة بطريقة مختلفة عما تفعله في Terminal؟ وعلى نطاق أوسع ، أود أن أشير إلى أن العديد من الميزات المطلوبة هنا (في هذا الموضوع وغيره) موجودة بالفعل في محطات أخرى ، كون ConEmu مجرد مثال واحد ، لذلك عندما يقترح مطورو Terminal ، لن يتم تنفيذ هذه الميزات أو عدم تنفيذها من أجل لفترة طويلة جدًا ، فأنت تؤكد ضمنيًا أنه لا ينبغي لنا استخدام Terminal.

إذا لم نعتمد على واجهات برمجة التطبيقات الموجودة فقط في عام 1903 ، فلن نطلب 1903.

@ DHowett-MSFT هل هناك أي وثائق عامة متاحة بخصوص ماهية واجهات برمجة التطبيقات ولماذا هي ضرورية؟ لأنني كمراقب خارجي ، عندما أرى هذا القرار وقرار استخدام UWP ، لا أرى القيمة المضافة. أرى فقط عقبات أمام إضافة ما يعتبره العديد من مستخدمي المؤسسة وظائف أساسية.

dadpolice راجع https://github.com/microsoft/terminal/issues/632#issuecomment -518888895 لمعرفة ما يفعله ComEmu.

اعتقدت أن "UAC ليست حاجزًا أمنيًا" وفقًا لمايكروسوفت؟ تمت معاملته مثل واحد في Vista. ثم قيل لنا إنها ليست مشكلة وأن أي مشكلة من هذا القبيل كانت مزحة في Windows 7. الآن هل هي مشكلة مرة أخرى اليوم؟

ربما تحتاج إلى مراجعة تصميم File Explorer والقائمة البيضاء UAC في هذه الحالة. :)

أم أنها تعتمد فقط على ما إذا كان ذلك عذرًا لاتخاذ اختصار في تصميم شيء لا يُسمح للمطورين العاديين بفعله (مستكشف الملفات) أو عدم تنفيذ ميزة أساسية (في هذه الحالة)؟

لا تنفذ ميزة أساسية (في هذه الحالة)؟

أريد أن أوضح - نحن لا نحاول _لا_ تنفيذ هذه الميزة. إنها بالتأكيد ميزة مهمة _ نريد_ تنفيذها. إنه شيء أواجهه يوميًا في الوقت الحالي - وجود نافذة مرتفعة ثانية هي _ OKay_ لكنها ليست _ جيدة_.

سيستغرق الأمر بعض الوقت حتى نتمكن من تصميم حل آمن بشكل مناسب ، ثم نقوم أيضًا بالجهود الهندسية لتنفيذه بالفعل. إنه شيء قمنا بوضعه على السبورة البيضاء لفترة من الوقت هذا الأسبوع.

@ zadjii-msft

[...]
لا أعتقد أننا نخطط لدعم علامات التبويب المختلطة المرتفعة وغير المرتفعة ، لأنها نوع من الثغرة الأمنية.
[...]

(كمسألة ربط المواضيع ذات الصلة ، # 146)

من الغريب أن الناس كانوا تحت الانطباع بأن الميزة لن يتم تنفيذها. علامة السخرية

@ kort3x هناك فرق بين "لا توجد خطة" (الملقب بأننا لا نعد بذلك) وعدم الرغبة في ذلك والقيام بما يمكنهم فعله لإيجاد طريقة لتنفيذه.

كما قال @ zadjii-msft:

سيستغرق الأمر بعض الوقت حتى نتمكن من تصميم حل آمن بشكل مناسب ، ثم نقوم أيضًا بالجهود الهندسية لتنفيذه بالفعل. إنه شيء قمنا بوضعه على السبورة البيضاء لفترة من الوقت هذا الأسبوع.

طالما لم يكن لديهم حل آمن ، فلن يخططوا (ويعرف أيضًا باسم الوعد) لدعم علامات تبويب الارتفاع المختلطة. أنا على استعداد لأن أكون على الرغم من أن الشخص الثاني الذي لديه حل آمن سيضيفه إلى الخطة (على الرغم من أنني لا أستطيع أن أعد بشيء).

اعتقدت أن "UAC ليست حاجزًا أمنيًا" وفقًا لمايكروسوفت؟ تمت معاملته مثل واحد في Vista. ثم قيل لنا إنها ليست مشكلة وأن أي مشكلة من هذا القبيل كانت مزحة في Windows 7. الآن هل هي مشكلة مرة أخرى اليوم؟

كما أفهم ، فإنه يمثل حاجزًا أمنيًا إذا تم تكوينه على أنه "يخطر دائمًا" ، وإلا فلن يكون كذلك.

حسنًا ، هذا مخيب للآمال. تعجبني المحطة (التي تقول الكثير ، لأنني مغرم جدًا بأدوات غير MS بشكل عام) ، لكن عدم القدرة على الرفع بسلاسة يمثل حاجزًا حقيقيًا أمامي للقيام بمزيد من العمل على نظام التشغيل هذا.

لول حسنا نعم ، أستطيع أن أرى كيف أن هذا محير. لقد كتبت هذا التعليق في الأصل بعد أيام من إعلاننا لأول مرة ، عندما لم تكن هناك خطة. بعد بضعة أشهر من المناقشة ، توصلت بالتأكيد إلى فكرة أن هذا قد يكون ممكنًا ، بمزيد من الجهد. سأقوم بتحديث التعليق ليعكس ذلك. SamuelEnglard محق بالرغم من ذلك ، من الصعب _ الالتزام_ بالقيام بذلك حتى نعلم أنه من الممكن القيام بذلك بشكل صحيح.

هذا مشجع لسماعه. هل من الممكن توسيع هذا الحماس للفرق الأخرى ، بحيث يمكن إصلاح # 3581 بالفعل؟

سيكون من الجيد أن تكون علامات التبويب عمليات مختلفة (على غرار الطريقة التي يديرها الكروم) في المقام الأول لأنه بعد ذلك لن أضطر إلى إعادة تشغيل جميع علامات التبويب بعد تجميعها بشكل جيد فقط للحصول على بيئة محدثة في واحدة علامة تبويب cmd ...
بمجرد أن يصبح Windows Terminal مجرد مدير ، يمكن تشغيله في وضع غير مرتفع مع الاستمرار في الاحتفاظ بموجهات أوامر مرتفعة. سيكون هذا لطيفا. (حسنًا ، سيكون رفع الوزن أثناء حمل المحطات الطرفية غير المرتفعة أمرًا جيدًا بالنسبة لي أيضًا)

@ rapus95 من الناحية الفنية ، فإن علامات التبويب هي ، من حيث أن "وحدة التحكم" هي عملية مختلفة. Windows Terminal هو مجرد مدير بالفعل

EDIT (فبراير 14 2020)
حسنًا ، لم يكن هذا التعليق مع تقدم العمر جيدًا. في الأصل ، كانت هناك _لا توجد خطة لدعم هذا ، لأنه لن يعمل مع الأغنية المنفردة HWND التي كانت لدينا. نحن نعمل على تصميم حل قد يدعم هذا في المستقبل ، لكن لا يمكننا الالتزام بأي شيء حتى نتأكد من أنه يمكننا التوصل إلى حل آمن بشكل مناسب ، يضمن عدم قدرة العملية ذات الامتيازات المنخفضة قيادة محطة امتياز أعلى.

بصرف النظر عن بعض النقاط الأخرى ، هذا هو السبب الرئيسي وراء استمرار استخدامي ConEmu . وأراهن أنني سأفعل ذلك.
https://conemu.github.io/ @ Maximus5

هذا في منتهى الغباء.

لنقم بإنشاء محطة طرفية موحدة جديدة لموجه الأوامر ، وبوويرشيل ، وباش للنوافذ.
هل يمكنني تشغيل cmd.exe كمسؤول؟
رقم.

أشياء غبية كهذه هي السبب في أن آلة عملي الرئيسية لا تزال Macbook.

hparadiz ألق نظرة على ConEmu :-D لا توجد مشكلات في تشغيل عدة قذائف كعلامات تبويب في نافذة واحدة ؛ حتى تشغيل جلسات Powershell و cmd.exe المرتفعة جانباً غير المرتفعة.

tmeckel هل نحن على يقين من أن conemu لا يحتوي على الثغرات الأمنية التي يقلق فريق المحطة الطرفية بشأنها؟ غالبًا ما يختار المستخدمون برامج أقل أمانًا لأنها تفعل ما يريدون ، ولكن على مسؤوليتهم الخاصة.

تضمين التغريدة سألت نفس السؤال أعلاه ، تمت الإجابة عليه في موضوع آخر: https://github.com/microsoft/terminal/issues/632#issuecomment -518888895

لقد كنت منتقدًا جدًا لـ Terminal حتى الآن ، ولكن لكي نكون منصفين ، فإن ConEmu و ConsoleZ وأدوات أخرى مماثلة موجودة بالفعل. لا توجد قيمة كبيرة في نسخ Microsoft لمجرد نسخها ، ولكن هناك قيمة كبيرة في إعادة إنشاء هذه الميزات بطريقة آمنة. ومع ذلك ، ما زلت أعتقد أنه من السخف جدًا إنشاء محاكي طرفي كتطبيق UWP خاص بالمتجر فقط ، خاصة الآن بعد أن يبدو أن Microsoft تبتعد عن UWP (على سبيل المثال ، يعد Edge الجديد تطبيق Win32).

ومع ذلك ، ما زلت أعتقد أنه من السخف جدًا إنشاء محاكي طرفي كتطبيق UWP خاص بالمتجر فقط ، خاصة الآن بعد أن يبدو أن Microsoft تبتعد عن UWP (على سبيل المثال ، يعد Edge الجديد تطبيق Win32).

لتوضيح الأمر ، فإن Terminal ليست متوفرة في المتجر فقط ( تتوفر ملفات .msix هنا ) ، كما أنها ليست تطبيق UWP. إنه تطبيق Win32 يستخدم UWP XAML كإطار عمل لواجهة المستخدم.

@ rapus95 من الناحية الفنية ، فإن علامات التبويب هي ، من حيث أن "وحدة التحكم" هي عملية مختلفة. Windows Terminal هو مجرد مدير بالفعل

حسنًا ، لماذا لم يتم تحديث البيئة لمثيل cmd جديد؟ أحتاج دائمًا إلى فتح Windows Terminal جديد مما يقلل إلى حد ما من قابلية الاستخدام الكلية لوجود علامات تبويب متعددة ...

@ rapus95 بينما أنا لست متأكدًا (يجب أن أذهب للبحث في الكود) أنا متأكد تمامًا من إطلاق كل عملية فرعية مع بيئة الوالدين وليست جديدة.

هذا لا يبدو منطقيًا بالنسبة لمدير المحطة

@ rapus95 إنه في الواقع خطأ نتعقبه هنا: # 1125

لتوضيح الأمر ، فإن Terminal ليست متوفرة في المتجر فقط ( تتوفر ملفات .msix هنا ) ، كما أنها ليست تطبيق UWP. إنه تطبيق Win32 يستخدم UWP XAML كإطار عمل لواجهة المستخدم.

هذا يبدو مثل UWP بخطوات إضافية. أيًا كان ما يجعله لا يمكنني النقر بزر الماوس الأيمن على Terminal وتشغيله كمستخدم مختلف ، كما يمكنني مع أي تطبيق Win32 عادي ، فقد كان هذا اختيارًا غريبًا.

إنه ليس تطبيق UWP ولا تطبيق Store فقط.
يحدث فقط أن إحدى طرق التوزيع هي Store ، والتي تتطلب حزمة UWP.
فقط أولئك الذين قاموا بتثبيته باستخدام المتجر لن يتمكنوا من Right click -> Run As Admin .
قم بإلغاء التثبيت واستخدام msix أو عبر السبق الصحفي

قم بإلغاء التثبيت واستخدام msix أو عبر السبق الصحفي

أو chocolatey .

gerardog لم أقل تشغيل كمسؤول ، قلت تشغيل كمستخدم مختلف.

ألا يناسبك Shift + Right Click ؟

(يرجى ملاحظة أنني قمت بالتثبيت باستخدام scoop )

لا ، لقد قمت بالتثبيت باستخدام حزمة msix وهذا الخيار غير موجود.

لقد قمت بتثبيت برنامج chocolatey ولم أقم بتشغيله كمسؤول أيضًا

لتوضيح الأمر ، فإن Terminal ليست متوفرة في المتجر فقط ( تتوفر ملفات .msix هنا ) ، كما أنها ليست تطبيق UWP. إنه تطبيق Win32 يستخدم UWP XAML كإطار عمل لواجهة المستخدم.

هذا يبدو مثل UWP بخطوات إضافية. أيًا كان ما يجعله لا يمكنني النقر بزر الماوس الأيمن على Terminal وتشغيله كمستخدم مختلف ، كما يمكنني مع أي تطبيق Win32 عادي ، فقد كان هذا اختيارًا غريبًا.

نفس الشيء هنا ، لقد جربت تطبيق msix و store. ما زلت لا أملك خيار "تشغيل كمستخدم مختلف".

ماذا عن جعل خلفية جميع علامات التبويب المرتفعة باللون الأحمر بحيث يكون من الواضح أنها مرتفعة؟

أفضل أن يكون هذا قابل للتكوين: لون الخلفية ، عنوان علامة التبويب ...

https://github.com/gerardog/gsudo يعمل بشكل جيد كحل مؤقت

ربما تنفذ شيئًا مثل wt elevated يفتح نافذة جديدة مرتفعة مع الغلاف الحالي بنفس البيئة.
تحرير: أو # 3158 ولكن كنافذة جديدة ومرتفعة

لا أفهم لماذا لا تنسخ الطريقة التي يقوم بها لينكس.

على حد فهمي أو عالم Linux (صححني إذا كنت مخطئًا) ، لا تحتاج التطبيقات الطرفية (gnome-terminal ، mate-terminal ...) إلى رفع مستوى حتى لو كتبت su أو sudo ونفذت الأمر كـ مستخدم الجذر. تتمثل المهمة الوحيدة للتطبيق الطرفي في تشغيل shell في عملية مختلفة (bash ، ksh ...) تكون مرتفعة أو غير مرتفعة ، وإعادة توجيه مدخلات ومخرجات shell حتى نتمكن من التفاعل مع shell.

إذا كتبت "su" أو بدأت أمرًا بـ "sudo" في محطة لينوكس ، فلن تفتح نافذة مختلفة.

gabsoftware لست متأكدًا من أمان هذا حتى على Linux. من الممكن أيضًا إرسال ضغطات المفاتيح إلى X windows في Linux ، وأعتقد أنه من الممكن إرسال ضغطات المفاتيح إلى عملاء المحطة الطرفية الذين يعملون في نافذة X حتى إذا تم رفع محطة التشغيل باستخدام sudo أو su. قد يكون من الممكن أيضًا إرسال ضغطات المفاتيح إلى نوافذ X مرتفعة ، لكنني حقًا لا أعرف على وجه اليقين.

لتوضيح الأمر ، فإن Terminal ليست متوفرة في المتجر فقط ( تتوفر ملفات .msix هنا ) ، كما أنها ليست تطبيق UWP. إنه تطبيق Win32 يستخدم UWP XAML كإطار عمل لواجهة المستخدم.

هذا يبدو مثل UWP بخطوات إضافية. أيًا كان ما يجعله لا يمكنني النقر بزر الماوس الأيمن على Terminal وتشغيله كمستخدم مختلف ، كما يمكنني مع أي تطبيق Win32 عادي ، فقد كان هذا اختيارًا غريبًا.

نفس الشيء هنا ، لقد جربت تطبيق msix و store. ما زلت لا أملك خيار "تشغيل كمستخدم مختلف".

لا يمكنني "التشغيل كمستخدم مختلف" عن طريق النقر بزر الماوس الأيمن على المربع الموجود في قائمة البدء ، ولكن يمكنني ذلك إذا قمت بالنقر بزر الماوس الأيمن فوق WindowsTerminal.exe

gabsoftware لست متأكدًا من أمان هذا حتى على Linux. من الممكن أيضًا إرسال ضغطات المفاتيح إلى X windows في Linux ، وأعتقد أنه من الممكن إرسال ضغطات المفاتيح إلى عملاء المحطة الطرفية الذين يعملون في نافذة X حتى إذا تم رفع محطة التشغيل باستخدام sudo أو su. قد يكون من الممكن أيضًا إرسال ضغطات المفاتيح إلى نوافذ X مرتفعة ، لكنني حقًا لا أعرف على وجه اليقين.

لقد أجريت بعض التجارب ، وأنا الآن متأكد من عدم الأمان في هذا على Linux. لست خبيرًا في الأمن ، لذا لست متأكدًا من تداعيات ذلك (أي شخص؟). تبين أنه من السهل حقًا إرسال ضغطات المفاتيح إلى نوافذ X التي قامت للتو بتشغيل sudo وهي مفتوحة لأوامر sudo الجديدة دون طلب كلمة مرور. منشور مدونة هنا ، آسف على المكونات المخزية ...

استنتاجي هو أنه ما لم تكن هناك طريقة لمنع إرسال ضغطات المفاتيح إلى نوافذ ذات ارتفاع مختلط ، فيجب أن يتم تنفيذ ذلك فقط كخيار للمستخدمين الراغبين في قبول المخاطر (علامات التحذير الكبيرة ، وما إلى ذلك).

كملاحظة جانبية ، كيف ترسل لوحة مفاتيح Windows على الشاشة ضغطات المفاتيح إلى النوافذ المرتفعة؟

لقد أصدرت gsudo v0.7 وهو وثيق الصلة بهذا الموضوع:

تحرير: بالنسبة إلى السياق: gsudo هو sudo للنوافذ ، ويسمح برفع أمر بسيط أو قذيفة في وحدة التحكم الحالية. عندما يتم استدعاؤه من Cmd / Pwsh داخل WT ، فإنه يرفع علامة التبويب. أيضًا ، يمكنك تحرير ملف التعريف الخاص بك ، وتسميته "Elevated Powershell" وتغيير الأمر إلى gsudo Powershell و voilá ، لديك ملف تعريف علامة تبويب مرتفع. انظر هنا .

ولكن نظرًا لأن gsudo ، أو أي sudo للنوافذ ، يقفز فوق عزلة UAC ، فقد تم تصنيفها على أنها "غير آمنة". ما يلي هو حل بديل أكثر تعقيدًا يسمح لك بعمل ارتفاعات مختلطة لعلامات التبويب مع الحفاظ على الأمان. / نهاية التحرير

يمكن لـ gsudo الآن تشغيل التطبيقات بأي مستوى من التكامل. على سبيل المثال ، يمكننا إطلاق Windows Terminal بمستوى تكامل MediumPlus ، وهذا يعني وضع "شبه مرتفع": حقوق لا يملكها المسؤول ولكنها معزولة ، ولا يمكن الوصول إليها من العمليات العادية الأخرى (ذات النزاهة المتوسطة). (ستظهر نافذة UAC المنبثقة)

لذلك ، يجب أن تكون الخطوة الأولى دائمًا تشغيل WT بـ: gsudo -i MediumPlus WT
(يمكنك تغيير اختصار WT الخاص بك). هذا يحمي WT من العمليات الضارة ، وإلغاء قفل الشاشة ، ومفاتيح الإرسال ، وحقن dll ، وما إلى ذلك.
(تحرير: إذا لم يعمل استخدم: gsudo -n -i MediumPlus cmd /c cmd /c start wt )

ثم يمكنك استخدام gsudo بأمان داخل WT لرفع الأوامر ، أو حتى إنشاء ملف تعريف مرتفع باستخدام ملفات التعريف "commandline": "gsudo cmd.exe" .

استنتاجي هو أنه ما لم تكن هناك طريقة لمنع إرسال ضغطات المفاتيح إلى نوافذ ذات ارتفاعات مختلطة ... يجب أن يتم تنفيذ هذا فقط كخيار للمستخدمين الراغبين في قبول المخاطر (علامات التحذير الكبيرة ، وما إلى ذلك).

خلص و أنتهى. (لقد أضفت تحذيرات الأمان إلى gsudo).

أيضًا ، منذ أن علمت أنه إذا كان المستخدم يستدعي gsudo من عملية تكامل عادية / متوسطة ، فإن ذاكرة التخزين المؤقت لبيانات اعتماد gsudo (ميزة إظهار عدد أقل من النوافذ المنبثقة لـ UAC) لا يمكن حمايتها بالكامل ... لذا ، الآن بيانات الاعتماد يجب تمكين ذاكرة التخزين المؤقت بشكل صريح عبر gsudo cache on/off أو gsudo config cachemode auto .

تبين أن "Changing your WT shortcut" ليس تافهًا على الإطلاق: نظرًا لنموذج MSIX / AppStore ، واجهت # 4217 و # 4459.

يعمل البرنامج النصي التالي بوويرشيل على حل هذه المشكلات لإنشاء اختصار Windows Terminal على سطح المكتب وربطه بمفتاح الاختصار 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()

بمجرد أن تبدأ WT كـ MediumPlus (مثل Ctrl + Alt + T) ، يمكنك استخدام gsudo كما هو مذكور [أعلاه] (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) لرفع الأوامر في ما يجب أن يكون AFAIK آمنًا.

الحل البديل لهذا هو استخدام Luke Samson 's _Sudo for Windows . تكوين الملف الشخصي هو:
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
عند بدء علامة تبويب جديدة بهذا الملف الشخصي ، تنبثق UAC ثم ينتهي بك الأمر في Powershell Core المرتفع. يعمل أيضًا مع أي محطة أخرى.
"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 Terminal كمسؤول وتجاوز 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 -owershell-tab-with-admin-الامتياز

drdamour بمجرد وجود خطة _is_ ، أود إزالة هذا القسم. على الرغم من ذلك ، في الوقت الحالي ، هناك فقط خطة للبحث عن طريقة لوضع خطة. بمجرد وجود خطة حقيقية وطريقة يمكننا القيام بها بأمان ، سأزيل هذا القسم.

الطريقة التي وصفها KMoraz تعمل بشكل رائع كحل بديل في الوقت الحالي. أشكركم على نشر هذا.

مرحبا الناس ،

كنت أستخدم ConsoleZ حتى اكتشفت هذا بالأمس.
تحتوي ConsoleZ على بعض الميزات وأحدها هو بدء علامة تبويب جديدة كمسؤول باستخدام 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

تحديث 21 مايو 2020:
ما ورد أعلاه يستخدم للعمل قبل الإصدار 1.0.1401.0.

راجع هذه المشكلة الجديدة أيضًا: https://github.com/microsoft/terminal/issues/6013

الآن لا يعمل النقر فوق Crtl-Shift إما عندما تضطر إلى الترقية باستخدام حساب مسؤول محلي.

شاهد لقطة الشاشة أدناه للخطأ التي أحصل عليها بعد أن طُلب مني مرتين لرفع الأذونات:

للحصول على معلومات ، يعد 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 كمسؤول

في الواقع مناسب جدًا ، لكن هذا يعمل فقط للحسابات الأعضاء في مجموعة المسؤولين.

إذا كنت تعمل كمسؤول لشخص آخر ، فلن تتمكن من تشغيل Windows Terminal كمستخدم (مسؤول) من حسابه.

أعتقد أنه سيكون من الجيد أن يكون لديك إعداد علامة تبويب واحدة لتشغيل cmd كمسؤول وليس كل شيء.

أعتقد أنه سيكون من الجيد أن يكون لديك إعداد علامة تبويب واحدة لتشغيل cmd كمسؤول وليس كل شيء.

كما هو موضح في مكان آخر هنا ، هذا غير ممكن مع التصميم الحالي.

هل هناك علم يمكن استخدامه للتشغيل كمسؤول؟ ثم يمكننا فقط إنشاء اختصار لها.

إذا قمت بتثبيت Windows Terminal على شريط المهام ، فيمكنك تشغيله _تحلي_ باستخدام Ctrl + Shift + click.

سيؤدي هذا إلى القيام بنفس الشيء مثل النقر بزر الماوس الأيمن على الرمز ، والنقر بزر الماوس الأيمن على "Windows Terminal" ، متبوعًا بـ "تشغيل كمسؤول".

ملاحظة: يعتبر Windows Terminal أحد تطبيقات المتجر ، ولا يمكنك تشغيله كمستخدم آخر.

أود أن أرى القدرة على الحصول على "علامات تبويب بمستوى تكامل مختلط" في Windows Terminal ، مع مستوى السلامة كخيار في كل ملف تعريف. هذا في الغالب كوسيلة راحة في عمل مسؤول النظام / مطوري النظام العادي لتقليل مقاطعات سير العمل وتبديل السياق.

لقد وجدت بديلاً بسيطًا يناسبني في الوقت الحالي. هذا لا يعالج جميع السيناريوهات المقدمة هنا من قبل المستخدمين الآخرين. لا يعتمد على تطبيقات الطرف الثالث أو ملفات الاختصارات أو مجموعات المفاتيح أو المهام المجدولة. لا يتطلب تحديد موقع Windows Terminal القابل للتنفيذ. يقوم فقط بعمل إدخال منفصل في قائمة ملف تعريف Windows Terminal الذي يقوم بتشغيل مثيل Windows Terminal الثاني مرتفعًا. يؤدي هذا إلى تشغيل مطالبة UAC مرة واحدة. أستخدم هذا فقط إذا احتجت إلى الارتفاع.

والنتيجة هي اثنين من محطات Windows. أي شيء في أحدهما قياسي وأي شيء في الآخر مرتفع. بالنسبة لي ، هذا مستوى مقبول من المقاطعة وتبديل السياق. تضيف Windows Terminal المرتفعة أيضًا عنوان كل علامة تبويب إلى "المسؤول:" مما يعطي تأكيدًا مرئيًا جيدًا للاختلاف.

تحرير: لدي Powershell 7 مثبتة ،

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

@ IarwainBen-adar ، يبدو أنني أتذكر القراءة مؤخرًا في المستندات الجديدة أنه لا يمكنك استخدام العنصر commandline والعنصر source معًا. هل يعمل بالشكل المتوقع بدون العنصر source ؟

لقد جربت الكود الخاص به ولا يمكنني حتى إظهار العنصر الجديد في السحب
القائمة السفلية.

@ shem-sargent آسف لذلك ، لقد حذفت تعليقي هنا لأن إعلان source الغريب كان بالفعل المشكلة. على الرغم من أن إدخال القائمة يعمل الآن ، إلا أنه لسوء الحظ ما زلت لا أستطيع تشغيل مثيل مرتفع من Windows Terminal - فأنا أواجه المشكلة رقم 3145 مع فشل The file cannot be accessed by the system.

@ IarwainBen-adar آسف ، لا يمكنني إعادة إنتاج # 3145. خلاف ذلك ، سأحاول استكشاف الأخطاء وإصلاحها من طرفي.

تثبيت في شريط المهام والتحول + النقر بزر الماوس الأيمن

هتاف LordFPL وبالطبع gerardog ، لم أسمع قط عن gsudo (https://github.com/gerardog/gsudo للآخرين المهتمين) من قبل ، لكن هذا يجعل الجلسات المرتفعة نسيمًا الآن. شكرا! قم بإضافته إلى كائن الملف الشخصي في ملف الإعدادات ، أو استخدم الاسم المستعار sudo كما تفعل في نظام Linux. في احسن الاحوال!

@ zadjii-msft اعتذاري ، لكنني لا أفهم بالضبط ما هي المشكلة هنا. يدعم Windows التلاعب بالرموز وانتحال الهوية ، كيف تعمل Runas أليس كذلك؟ باستخدام gsudo منgerardog ، يمكنني الحصول على تكامل منخفض (er) يستضيف قشرة تكامل عالية (er) في نفس الوقت مثل أي غلاف تكامل مستوى آخر ، سواء كان ذلك powerhell أو pwsh أو cmd أو أي غلاف wsl. من خلال الاختبار المحدود الذي أجريته ، لا يمكن لأي من قذائف النزاهة المنخفضة تصحيح الأخطاء في غلاف التكامل العالي هذا. ما هو العائق هنا لامتلاك هذا كمحطة طرفية مدمجة ، أو حتى أكثر تفضيلاً على مستوى نظام التشغيل؟

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

نافذة منخفضة (er) - تكامل _ تلقي المدخلات وتوجيهها مباشرة إلى عملية تكامل عالية (er) - تفتح تلك العملية (er) عالية التكامل حتى للتحكم من خلال أشياء أخرى منخفضة (er) - سلامة على النظام.

هذا يعني أن العملية التي يحتمل أن تكون ضارة تحتاج فقط إلى تحرك جانبي على نفس مستوى الامتياز للحصول على EoP.

@ smokeintheshell # 632 (تعليق)

نافذة منخفضة (er) - تكامل _ تلقي المدخلات وتوجيهها مباشرة إلى عملية تكامل عالية (er) - تفتح تلك العملية (er) عالية التكامل حتى للتحكم من خلال أشياء أخرى منخفضة (er) - سلامة على النظام.

هذا يعني أن العملية التي يحتمل أن تكون ضارة تحتاج فقط إلى تحرك جانبي على نفس مستوى الامتياز للحصول على EoP.

نعم ، لقد قرأت هذا الشرح في بداية الموضوع ، لكنني لا أفهم سبب كونه مناسبًا لنظام التشغيل Linux ، وربما Mac ، ولكن ليس مناسبًا لنظام التشغيل Windows؟ يحمي Windows حاليًا الإدخال إلى العمليات المرتفعة من العمليات غير المتطورة. في هذه المشكلات أو في مشكلة ذات صلة ، اقترح أحدهم أننا بحاجة إلى عملية منفصلة لكل علامة تبويب. أعتقد أن هذا هو الحال بالفعل لأن كل علامة تبويب لها أمر خاص بها للتنفيذ (على سبيل المثال: pwsh.exe). هل لأنهم جميعًا أطفال من نفس عملية الجذر تحت 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 (عدم الحاجة إلى إدخال كلمة المرور الخاصة بك في أمر sudo التالي في غضون 15 دقيقة) ، تجعل هذا الأمر أسهل. يمكنك تقوية Ubuntu عن طريق تعطيل الامتداد X الضروري للهجوم. لست متأكدًا مما إذا كان هذا ممكنًا في بيئة Wayland (الهجوم و / أو التصلب).

أتفهم تمامًا قرار عدم تنفيذ علامات تبويب ذات ارتفاعات مختلطة ، ما لم تكن هناك طريقة ما لتعطيل لوحات المفاتيح الافتراضية وطرق إدخال البرامج الأخرى.

أعتقد أن هذا هو الحال بالفعل لأن كل علامة تبويب لها أمر خاص بها للتنفيذ (على سبيل المثال: pwsh.exe). هل لأنهم جميعًا أطفال من نفس عملية الجذر تحت HWND واحد؟

kbirger نعم ، هناك عمليات منفصلة لكل علامة تبويب ، ولكن لا يزال يتم إرسال جميع مدخلات الماوس ولوحة المفاتيح إلى نافذة Windows Terminal (وهي منخفضة التكامل) ، ثم يتم توجيهها إلى كل عمليات shell عبر تدفقات الإدخال القياسية. هذه هي الطريقة التي تعمل بها جميع اختصارات لوحة مفاتيح Windows Terminal.

أتساءل عما إذا كان من الممكن اكتشاف ما إذا كان الإدخال مزيفًا ، على سبيل المثال باستخدام GetCurrentInputMessageSource API. لا يمكنني العثور على الكثير من المعلومات حول واجهة برمجة التطبيقات هذه بخلاف المثال الرسمي ، ولكن من الوصف يجب أن يكون قادرًا على تحديد مصدر الإدخال (الأجهزة / من العمليات باستخدام uiAccess ، معظمها برامج إمكانية الوصول / من العمليات التي لا تحتوي على uiAccess ، ربما تكون ضارة)

لماذا يعتبر هذا مناسبًا لنظام التشغيل Linux وربما Mac ، ولكنه غير مناسب لنظام التشغيل Windows؟

أنا متأكد تمامًا من أن أحد الأسباب الثلاثة هو أن Microsoft تبيع الأمان كميزة لشركات أو حكومات كبيرة أخرى.

هناك أيضًا بعض الأصداء الأخرى التي تتبادر إلى ذهني حول سبب عدم وجود مشكلة حتى الآن:

• لفترة طويلة ، ولعدة أسباب (مثل "المتسللين" الذين لا يحبون Windows ، و "كل شخص" يستخدم Windows ^^) ، اعتاد Windows أن يكون الهدف الأساسي (≈ فقط) لجميع أنواع البرامج الضارة. لقد احتاج إلى أمان أفضل (حماية النوافذ المرتفعة) ، بينما لم يهتم الآخرون كثيرًا.
• كما هو موضح سابقًا في هذه المشكلة ، لا ينبغي أن يكون من الممكن للبرامج الضارة الوصول بسهولة إلى مضيف وحدة التحكم المرتفع على Windows ، لذلك من المحتمل ألا يستثمر الكثيرون في هذه المشكلة (لست خبيرًا في الأمان ، لذلك لا أعرف إذا كان لدى البعض)
• عادةً ما يكون للبرامج الضارة طرق أخرى للارتقاء بنفسها بدلاً من محاولة العثور على موجه أوامر مرتفع في نظام التشغيل الذي تختاره
• المطورين ومسؤولي النظام فقط هم من يستخدمون المحطات الطرفية (وهذا يقلل فقط الديموغرافية المستهدفة للهجوم ؛ الحكومات والشركات الكبيرة لا تزال مصدر قلق)

الآن ، من خلال تقديم الميزة بسذاجة (كما فعلنا جميعًا ، أنا متأكد 😄) من أنك ستدخل عيبًا جديدًا (ضخمًا) في بعض عمليات تثبيت Windows. مع إجراء التطوير في العراء ، يمكنك التأكد من أن كل شخص محتاج سيكون على دراية بالعيوب ويبدأ في الترميز ضده.
يتمثل الإجراء المضاد السريع في حظر Windows Terminal (ومن المحتمل أن تكون جميع برامج المحاكاة الطرفية الأخرى الموجودة الآن بعد أن أصبح الخلل عامًا) ، يمكنك بعد ذلك تقبيل وداعًا لأحلامك في استخدام Windows Terminal في أي نوع من بيئة الشركة 😟

ما زلت آمل بشدة أن ترى نسخة آمنة من هذه الميزة ضوء النهار ، رغم ذلك 🤞

أنا أرى. شكرا على التفسيرات!

كملاحظة جانبية ، كيف ترسل لوحة مفاتيح Windows على الشاشة ضغطات المفاتيح إلى النوافذ المرتفعة؟

هناك ثلاث طرق لإرسال المدخلات إلى النوافذ المرتفعة mrwensveen AFAIK:

1. ارفع من نفسك. ومع ذلك ، لا يزال يتعذر عليك إرسال مدخلات إلى عمليات النظام (مثل مدير المهام ومربع حوار التحكم بحساب المستخدم وشاشة تسجيل الدخول).
2. قم بتسجيل خدمة Windows. الآن يعمل برنامجك كنظام SYSTEM حتى تتمكن من فعل أي شيء تريده. لقد رأيت بعض برامج الوصول عن بعد تفعل ذلك.
3. قم بتعريف العلم uiAccess ، وقم بالتوقيع رقميًا على ملفك الثنائي ، وقم بالتثبيت في موقع غير قابل للكتابة للمستخدم الحالي. إنه "باب خلفي" لبرامج إمكانية الوصول ، مما يسمح لهم بقراءة / كتابة أي برامج أخرى (بما في ذلك عمليات النظام) ، والعرض أعلى أي نوافذ أخرى (بما في ذلك Secure Desktop حيث تظهر النوافذ المنبثقة لـ UAC وشاشة تسجيل الدخول) ، كل ذلك بدون تشغيل مرتفع. راجع https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

تستخدم لوحة المفاتيح على الشاشة (osk.exe) و Narrator.exe (وربما قارئات الشاشة الأخرى) الطريقة الثالثة.

(لقطة شاشة تعرض بيان البرنامج المضمن لـ osk.exe مع uiAccess=true )

يبدو أن العلم uiAccess يمكنه أيضًا حماية البرنامج من الوصول إليه من قبل برامج أخرى منخفضة التكامل (على الرغم من استمرار تشغيله بدون ترقية) ، فربما يمكننا استخدام هذه "الميزة" لحماية WT؟

@ yume-chan Cool ، هذا مثير جدًا للاهتمام ، شكرًا! هل يُسمح لبرامج uiAccess بإرسال ضغطات المفاتيح إلى برامج uiAccess الأخرى؟ ما زلنا نريد أن يكون OSK قادرًا على التفاعل مع windows Terminal ، وإذا كان هذا يعني أنه يجب توقيع برامج أخرى على الأقل قبل السماح بإرسال مدخلات إلى windows terminal ، فهل هذا عائق مرتفع بدرجة كافية؟

هل يسمح لبرامج uiAccess بإرسال ضغطات المفاتيح إلى برامج uiAccess الأخرى؟

mrwensveen نعم ، يمكن للبرامج ذات الامتياز uiAccess الوصول إلى بعضها البعض.

أنا أفضل طريقة API GetCurrentInputMessageSource (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562) لأن هذا ليس استخدام uiAccess المقصود. مع واجهة برمجة التطبيقات أيضًا ، قد لا نزال نسمح للبرامج منخفضة التكامل بإرسال ضغطات المفاتيح إلى علامات تبويب غير مرتفعة ، بينما لا نسمح للبرامج منخفضة التكامل.

القليل من الحل الذي أجريته هنا:

لقد قمت بتثبيت PowerToys الذي يحتوي على بعض الميزات الرائعة. أحدها هو إظهار اختصارات windows واكتشفت أنه عند الضغط على Win + number ، فإنه يفتح التطبيق في شريط windows المقابل للرقم الذي يظهر في الشريط.

لذلك ، لقد قمت بوضع الجهاز في الشريط كأول أيقونة
.

عندما أضغط على Win + 1 ، يتم فتح الجهاز.

عندما أضغط على Win + Ctrl + Shift + 1 ، فإنه يفتح مرتفعًا.

سأضع تكوين الجهاز وملف تعريف powerhell الخاص بي هنا أيضًا إذا كنت تريد الحصول على ميزات إظهار فرع git وبيئة conda في الموجه والمستخدم باللون الأحمر إذا كانت محطة مرتفعة ...

هذا موجود منذ Windows 7 على الأقل ؛ إنه ليس شيئًا PowerToys.

Firehawke نعم ، لقد اكتشفت للتو بسبب PowerToys ... ليس هناك حاجة إلى ذلك.

إليك ملف تعريف لبدء تشغيل مرتفع يعمل على متجر Windows وله رمز مناسب:

{
    "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 ، يبدو أن بعض الأشخاص قد واجهوا الرقم 4228 (خطأ 0x80070002 عند التشغيل) بسبب متغيرات بيئة PATH التالفة أو الثنائيات الغريبة في مسارهم المسماة powershell.exe أو pwsh.exe . قامzurkz بإصلاح هذا من خلال الرجوع إلى powershell.exe ، لكنني لا أعتقد أن هذا موثوق به الآن. يعالج # 6684 هذه المشكلة لـ Windows Terminal ، وستجد إصدارًا ثابتًا أدناه ، باتباع هذا الحل ، والذي لا ينبغي أن يكون به هذه المشكلة على الإطلاق.

إليك ملف تعريف لبدء تشغيل مرتفع يعمل على متجر Windows وله رمز مناسب:

{
    "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 وله رمز مناسب:

{
    "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 وله رمز مناسب:

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

@ أي شخص سامح جهلي ، هل يتم إسقاط هذا في تهيئة متجر Windows؟ إذا كان الأمر كذلك ، هل يمكن لأي شخص نشر المسار؟ إذا لم يكن كذلك ، أين من المفترض أن يعيش هذا الولد الشرير؟

TYIA!

تضمين التغريدة
ينتقل في ملف Windows Terminal settings.json ، في قسم ملفات التعريف.

يتسبب في حدوث خطأ: 0x80070002 عند الإطلاق. pwsh 7.1.0 تحديث

لقد غيرتها إلى:

{
    "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 Terminal مرتفعًا إذا تم تثبيته في قائمة البدء.
https://github.com/farag2/Utilities/blob/master/Windows٪20Terminal/Pin٪20to٪20Start.ps1

narfanar يبدو أنك واجهت # 4228 ، حيث يصدر Windows Terminal الخطأ 0x80070002 عند بدء التشغيل عندما يكون متغير بيئة PATH معطلاً أو تطفو ثنائيات أخرى في المسار المسمى powershell.exe أو 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"
}

وحدة التحكم ض تفعل هذا بشكل جيد

لاحظ أن Cmder لديه هذه الميزة ، وهي مفيدة بشكل لا يصدق. أحب أن أراها مطبقة في Windows Terminal. حتى إذا كان عليه تشغيل نافذة منفصلة لعلامات تبويب المسؤول أو شيء من هذا القبيل ..

ملف التعريف الافتراضي الخاص بي مضبوط على bash بدلاً من بوويرشيل ، وأود الاحتفاظ به بهذه الطريقة. المقتطف أعلاه يعمل بشكل رائع ، لكن معرف الحب لتكون قادرًا على جعله يطلق محطة مرتفعة جديدة مع تحميل ملف تعريف powerhell. لقد أمضيت 3 ساعات في محاولة اكتشاف ذلك (لست معجبًا كبيرًا / لديك خبرة كبيرة مع بوويرشيل) ولا يمكنني معرفة ذلك - مساعدة pleaaaase. يبدو أن هناك مزيجًا من علامات الاقتباس الفردية ، والاقتباسات المزدوجة ، والهروب ، والمسافات ، والأسطر الجديدة ، والتي قد تجعلها تعمل ولكن لا يمكنني الحصول على عملية البدء وقائمة الحجج لفعل ما أريد. غليه حتى:

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
يعمل هذا في ملف .ps1 إذا قمت بتشغيله بنفسي ، فسأحصل على محطة طرفية جديدة مرتفعة للنوافذ مع تحميل ملف تعريف بوويرشيل. لكنه لا يعمل في معلمة سطر الأوامر الخاصة بـ settings.json ، بغض النظر عن كيفية محاولتي إفسادها ، استدعاء قائمة الوسيطة صراحةً بدلاً من استخدام cmd / c ، وأشكال مختلفة من استخدام الهروب والاقتباس ، إلخ.

"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 الخاص بي ولكنها في الواقع تعمل بوويرشيل. الخط الخاطئ وكل شيء. إذا استخدمت هذه النافذة لفتح علامة تبويب بوويرشيل جديدة ، فسيتم رفعها حسب الرغبة. عندما يكون الأمر على هذا النحو ، يمكنني لصق أي شيء مهمل أريده في جزء "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

هل لا يزال أي شخص آخر يعاني من المشكلة أو لم يتمكن من تشغيلها على ما يرام؟

ملف التعريف الافتراضي الخاص بي مضبوط على 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 حتى لا يظهر عنوان علامة التبويب " المسؤول": باعتباره مكررًا مع Elevated .

ayfine إذا كان https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 لا يعمل بالفعل من أجلك ، فهل يمكنك إرسال نسخة من الأخطاء الدقيقة / السلوك غير المتوقع الذي تحصل عليه مع هذا التكوين؟ (تأكد من إضافة تكوين إضافي ، مثل suppressApplicationTitle ، بأكبر قدر ممكن من الخطوات ، بحيث إذا كان أي من التكوين الخاص بك يكسر WT ، فسيكون من الأسهل معرفة مكان ووقت حدوثه.)

إذا كانت أي تكوينات أخرى هنا أبعد قليلاً من التكوينات المرتبطة بالنسبة لك ، فسيكون موضع تقدير أيضًا تفاصيل حول كيفية تعطل هذه التكوينات.

@ bb010g لا أواجه أي رسائل خطأ - أعتذر عن عدم الدقة في ردي. عند استخدام https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 واجهت مشكلة Windows Terminal في تحميل WSL Ubuntu shell (الافتراضي). لقد اعتبرت هذا في الأصل يعني أنه لا يعمل بشكل صحيح ولكني أرى الآن أنه في تلك النافذة الجديدة ، إذا بدأت علامة تبويب Powershell جديدة (ملف تعريف افتراضي) ، فهي في الواقع مرتفعة. بغض النظر ، عن طريق فتح نافذة جديدة والاضطرار إلى بدء علامة تبويب جديدة داخلها ، فإن الأمر ليس أسهل من تشغيل عملية مرتفعة من قائمة البداية الخاصة بي. ما وصفته في ردي الأصلي يوفر السلوك الدقيق الذي كنت أتخيله.

ayfine - وقمت بنسخ مثال gsudo الخاص بك. هذا حل جيد بما فيه الكفاية حتى يتم ترميز شيء مضمن. شكرا.

ayfine لقد جربت شيء gsudo ، لكنها تجربة مروعة جدًا. يبدو أن أي نوع من إكمال TAB متقطع ، ولا يبدو أن أحرف Unicode (غير ASCII) تظهر. أظن أنها عملية تعيد توجيه المدخلات والمخرجات ، وتقوم بعمل رهيب فيها. أعتقد أن الحل مع نافذة منفصلة يعمل بشكل أفضل.

إذا كنت تواجه مشكلات مع gsudo ، فيرجى الإبلاغ عنها إلى gerardog وليس في سلسلة الرسائل هذه. كل رسالة في هذا الموضوع (هذه الرسالة ؛ آسف!) ترسل مئات المشتركين بالبريد الإلكتروني.

سأقوم بتأمين هذا الموضوع لمزيد من التعليقات لغير المشرفين ، لأننا نصل إلى النقطة التي لا تؤدي فيها التعليقات الإضافية إلى دفع المناقشة إلى الأمام قدرًا ذا مغزى.

يرجى تقديم مشكلات جديدة إذا كانت لديك مخاوف لم يتم تناولها هنا.