Terminal: [Pertanyaan] Mengkonfigurasi profil Terminal Windows untuk selalu meluncurkan yang ditinggikan

Tidak ada. Saya tidak berpikir kami berencana untuk mendukung tab campuran yang ditinggikan dan tidak ditinggikan, karena ini sedikit lubang keamanan.

Ya saya tahu sudo adalah suatu hal, tetapi kami telah banyak berdiskusi dengan tim keamanan tentang pembuatan sudo untuk Windows. Masalah utama adalah karena fakta bahwa setiap proses yang tidak ditinggikan dapat mengirim penekanan tombol ke jendela yang tidak ditingkatkan lainnya.

Jika Anda memiliki baris perintah yang ditinggikan yang berjalan di jendela yang tidak ditinggikan, aktor jahat yang tidak tepercaya dapat melakukan serangan elevasi-of-hak istimewa dengan menggerakkan jendela yang tidak ditinggikan yang menjalankan baris perintah yang ditinggikan.

(sebagai masalah menautkan utas terkait, #146)

EDIT (14 Februari 2020)
Oke, jadi komentar ini tidak terlalu matang. Awalnya, ada _no_ rencana untuk mendukung ini, karena itu tidak akan bekerja dengan HWND tunggal yang kami miliki. Kami sedang berupaya merancang solusi yang _might_ mendukung ini di masa mendatang, tetapi kami tidak dapat berkomitmen pada apa pun sampai kami yakin bahwa kami dapat menemukan solusi aman yang tepat, yang memastikan bahwa proses dengan hak istimewa yang lebih rendah tidak dapat drive terminal hak istimewa yang lebih tinggi.

Tampaknya masuk akal. Saya pikir memiliki sesuatu seperti kombinasi #576 (Buka sebagai Admin di daftar lompat), dan mungkin semacam hotkey untuk meluncurkan sesi Admin Terminal akan menyelesaikan sebagian besar rasa sakit saya di sini.

Bagaimana dengan memiliki Terminal standar dan yang ditinggikan terbuka di satu jendela tetapi tab terpisah?

@mdtauk Saya pikir sayangnya termasuk dalam kategori yang sama. Karena semua tab berada di bawah HWND yang sama, root HWND adalah yang perlu dinaikkan untuk mencegah aplikasi yang tidak ditinggikan mendorong jendela.

Dari sudut pandang keamanan (mengabaikan desain Terminal Windows, root tunggal HWND, dll.), seberapa "kurang aman" Terminal menjalankan tab elevasi campuran dibandingkan dengan menjalankan, katakanlah, satu instans PowerShell yang ditinggikan di sebelah satu instans yang tidak ditinggikan di UX saat ini ? Fakta bahwa aplikasi konsol di-host di tab Terminal tidak membuat perbedaan bagi saya ...

Pada catatan serupa: Bagaimana memiliki jendela yang tidak ditinggikan lebih aman bahkan jika saya membuka sesi PS jarak jauh di mana saya sekarang mungkin memiliki hak admin di server jarak jauh yang sekarang dapat dikendarai oleh yang tidak ditinggikan. Bagi saya ini tampaknya jauh lebih buruk daripada mendapatkan akses admin lokal, jadi saya tidak berpikir bahwa menjalankan tab sebagai admin berbeda dari meremoting / ssh-ing ke server lain. Dalam kedua kasus, saya perlu merasa cukup nyaman dengan sistem saya untuk melakukannya. Ini adalah hal "Saya cukup tua dan saya mengerti risikonya".

Setiap kali saya mencoba menjalankan aplikasi Terminal dengan akun administrator, klik kanan -> jalankan sebagai administrator, UAC muncul dua kali dan terjadi kesalahan yang mengatakan:
"Windows tidak dapat menemukan (path\WindowsTerminal.exe) Pastikan Anda mengetik ...".

Jalur ada dan aplikasi berfungsi dengan benar untuk pengguna non admin yang membuat aplikasi, tetapi pengguna administrator lain tidak dapat menjalankannya.
Jika saya masuk ke pengguna admin, aplikasi terminal tidak ada di pengaturan atau menu mulai, seolah-olah itu tidak pernah diinstal pada sistem.

Apakah ada cara untuk membuat aplikasi agar dapat diinstal untuk semua pengguna? Atau apakah root proyek harus berada di direktori khusus non-pengguna?

@

Setiap kali saya mencoba menjalankan aplikasi Terminal dengan akun administrator, klik kanan -> jalankan sebagai administrator, UAC muncul dua kali dan terjadi kesalahan yang mengatakan:
"Windows tidak dapat menemukan (path\WindowsTerminal.exe) Pastikan Anda mengetik ...".

Jalur ada dan aplikasi berfungsi dengan benar untuk pengguna non admin yang membuat aplikasi, tetapi pengguna administrator lain tidak dapat menjalankannya.
Jika saya masuk ke pengguna admin, aplikasi terminal tidak ada di pengaturan atau menu mulai, seolah-olah itu tidak pernah diinstal pada sistem.

Apakah ada cara untuk membuat aplikasi agar dapat diinstal untuk semua pengguna? Atau apakah root proyek harus berada di direktori khusus non-pengguna?

Saya melihat masalah yang sama terjadi juga.

Windows versi 18922.1000

Benar, jadi menjalankan aplikasi toko sebagai admin atau pengguna lain tidak berfungsi (berdasarkan desain BTW). Banyak dari kita masuk (ke PC) sebagai akun non-elevasi normal. Kami menjalankan powershell/cmd/etc sebagai admin untuk melakukan tugas tertentu.

Jika pilihan terakhir adalah untuk menyebarkan aplikasi ini adalah toko Windows, tidak ada gunanya bagi saya tanpa beberapa cara untuk membuka tab yang ditinggikan. 2 sen saya.

"Tidak berguna" mungkin agak kasar, tetapi memang kami membutuhkan cara untuk menggunakan terminal baru baik untuk aplikasi/kerang konsol yang tidak ditinggikan maupun yang ditinggikan. Dan bagi saya UX terbaik adalah mendukung campuran tab yang ditinggikan dan tidak ditinggikan dalam contoh Terminal Windows yang sama. Kurang disukai: mendukung nol hingga banyak (biasanya satu) instans yang ditingkatkan (masing-masing dengan satu hingga banyak tab) di samping nol hingga banyak (biasanya satu) instans yang tidak ditingkatkan.

ConEmu dapat menggabungkan tab yang ditinggikan dan tidak ditinggikan di jendela yang sama. Tidak bisakah hal seperti itu dilakukan di sini?

Bisakah kita memiliki Terminal yang lebih tinggi meluncurkan tab yang tidak ditinggikan? Saya masih perlu meluncurkan yang ditinggikan TETAPI saya dapat membuka tab baru yang "dilindungi".

Jika kita ingin menjadi sangat spesifik untuk Windows dan mengabaikan platform lain yang pada akhirnya mungkin melihat Terminal, mungkin penggunaan Windows Containers atau proses virtual dapat membantu masalah ini bagi sebagian orang. Saya pribadi baik-baik saja dengan solusi saat ini tetapi menjalankan aplikasi konsol sebagai proses yang terisolasi secara default tidak akan menjadi ide yang buruk dari sudut pandang keamanan.

Ketinggian campuran dalam satu jendela adalah suatu keharusan, setidaknya bagi saya.
Mungkinkah fitur opsional untuk diaktifkan dalam pengaturan?

@pratnala Dengan ConEmu hanya _terlihat_ seperti melakukan itu, tetapi sebenarnya tidak melakukan itu sama sekali. "Tab" yang ditinggikan dan tidak ditinggikan hanyalah tampilan menjadi dua jendela/proses root yang sepenuhnya terpisah dan terisolasi. Ia melakukan ini dengan mengikis konten windows antara lain dan pembantu elevasi proxy/broker dll. Tentu, secara teknis mungkin, tetapi apa yang dilakukan ConEmu sebenarnya agak tidak aman. Ini adalah satu hal bagi program pihak ketiga untuk melakukan ini dan membuat orang memilih mengambil risiko dengan mengunduh ConEmu, tetapi cukup lain bagi Microsoft untuk secara resmi mendukung ini dengan melakukan ini sendiri. Jika saya ingin menyembunyikan kunci pintu depan saya di bawah keset, maka baiklah - itu risiko bodoh yang harus saya ambil. Tetapi bagaimana jika setiap pintu yang Anda beli meletakkan satu set kunci di bawah keset?

Tapi lihat, saya mengembangkan di C++ (dan C#, PowerShell, Ruby, Python, GoLang, hampir semua hal yang datang kepada saya.) Saya telah menginstal ConEmu dan TakeCommand, bersama dengan mingw. Saya tahu cara memegang gunting saat saya berlari.

PowerShell _adalah_ lubang keamanan. Alat otomatisasi yang sangat berguna, memungkinkan segala macam akses tak terduga. Dan apa yang kami minta (mode campuran) tentu saja lebih aman daripada alternatif (semua ditinggikan.) Sungguh (terminal) ini adalah alat listrik untuk pengguna listrik, yang sebagian besar mungkin memahami lanskap keamanan dengan sangat baik... dan mengerti kompromi pragmatis.

Zero-trust hanya berfungsi jika tidak melemahkan.

@robomac Jika kami dapat meyakinkan tim keamanan (yang telah memberi tahu kami beberapa kali untuk tidak menjelajah jarak jauh mendekati ketinggian campuran) bahwa hanya orang yang tahu cara memegang gunting dengan benar dan tidak berlari bersama mereka yang akan _menggunakan_ proyek ini, kami mungkin akan melakukannya. Saya sendiri tidak tahu apakah saya percaya. Inilah alasannya:

Seperti tidak, jika Terminal berjalan dalam elevasi campuran (dari host Medium-IL ke klien High-IL), Terminal masih dapat dipaksa untuk menerima input oleh apa pun yang berjalan sebagai pengguna itu. Bahkan jika orang di belakang keyboard adalah orang suci dan hanya terangkat selama sepuluh detik yang dia perlukan untuk naik, _aplikasi apa pun yang berjalan di bawah akun penggunanya dapat menyamar sebagai administrator tanpa prompt elevasi tambahan_. Bahkan mungkin sama sekali tidak terdeteksi.

@DHowett-MSFT Saya berterima kasih atas tanggapan Anda. Anda membuat asumsi bahwa bagaimanapun juga kami mengizinkan proses jahat berjalan. Kami membatasi izin dari mantra "Praktik Terbaik" yang kami lakukan dengan pose anjing menghadap ke bawah setiap pagi, tetapi jika Anda benar-benar khawatir bahwa beberapa jam, bahkan, akses terminal yang ditinggikan membuat Anda berisiko _pada sistem Anda sendiri yang Anda sedang mengembangkan_ ...

1. Anda seharusnya tidak menjalankan Terminal dan
2. Anda harus menghapus dan memulai dari awal.

Saya akan memberi tahu Anda bahwa peneliti virus (komputer) tidak boleh mengambil risiko ini di jalur vektor ... tetapi bahkan sejak awal kami memasukkannya ke dalam kotak pasir di VM. Tapi "Terminal" bukan untuk kerabat Anda yang tidak paham; itu alat listrik.

Ada cara standar untuk menangani risiko. Dipersembahkan oleh dunia browser. Ketika Anda pergi ke bendera lanjutan, Anda menerima peringatan, kira-kira, "Inilah naga". (Saya pikir justru di Pale Moon... yang merupakan browser keamanan hard-core yang serius.) Tambahkan peringatan (non-UAC, tambahan), tetapi biarkan pengguna memutuskan.

Satu pertanyaan lain: Akankah dua sesi Terminal yang berbeda, satu ditinggikan, satu tidak, berperilaku seperti yang diharapkan? Atau akankah keduanya menjadi vektor untuk sesi apa pun?

Saya tidak setuju bahwa orang harus dapat memilih sesuatu seperti ini. :senyum:

dua sesi berbeda

Oh, ya, itu harus benar-benar berfungsi hari ini -- dan bukan menjadi vektor (yang ditinggikan sepenuhnya berjalan di sisi IL Tinggi dunia dan tidak dapat didorong oleh proses Medium-IL lainnya)

itu harus benar-benar berfungsi hari ini

Dengan semangat yang sama, tidak bisakah 2 tab berjalan dalam proses yang berbeda dan dengan demikian memungkinkan elevasi campuran di jendela yang sama?

@DHowett-MSFT Jadi, mengapa dua sesi berbeda tidak dapat di-host di aplikasi over-arching? Ini benar-benar tidak sulit untuk dilakukan.

Saya pikir saya memahami implikasi keamanan memiliki aplikasi konsol yang ditinggikan di tempat pertama, tetapi yang tidak dapat saya pahami adalah mengapa memiliki dua jenis tab (ditinggikan dan tidak ditinggikan) di dalam Terminal Windows akan _lebih berisiko_ daripada yang didukung Windows untuk usia yaitu menjalankan CMD / PowerShell yang ditinggikan dan tidak ditinggikan secara berdampingan. Dapatkah seseorang menjelaskan hal ini?

@robomac
[1] Ini sepele ketika Anda _hosting windows_ tradisional dengan pegangan jendela tradisional. Itu bekerja sangat baik dalam kasus conemu, atau dalam kasus shell tab, di mana Anda dapat mengambil alih jendela di sesi yang ditinggikan dan mengasuhnya kembali di bawah jendela di sesi yang tidak ditinggikan.

Ketika Anda melakukannya, ada beberapa fitur keamanan yang akan saya sentuh [2]. Karena itu, Anda dapat mengasuhnya tetapi Anda tidak dapat benar-benar memaksanya untuk melakukan apa pun.

Ada masalah. Terminal tidak dirancang sebagai kumpulan jendela yang dapat diasuh ulang. Misalnya, itu tidak menjalankan host konsol dan memindahkan jendelanya ke dalam tab. Itu dirancang untuk mendukung "koneksi" -- sesuatu yang dapat membaca dan menulis teks. Ini adalah tingkat primitif yang lebih rendah daripada jendela. Kami menyadari kesalahan cara kami dan memutuskan bahwa model UNIX benar sepanjang waktu, dan pipa dan teks dan aliran _di mana itu._

Mengingat bahwa kami menggunakan pulau-pulau Xaml untuk meng-host UI modern dan menggabungkan permukaan DirectX ke dalamnya, kami tetap jauh melampaui dunia pegangan jendela standar. Pulau Xaml sepenuhnya disusun menjadi satu HWND, seperti Chrome dan Firefox dan keseluruhan game DirectX/OpenGL/SDL. Kami tidak memiliki komponen yang dapat dijalankan dalam satu proses (ditingkatkan) dan di-host di yang lain (tidak ditinggikan) yang bukan "koneksi" yang disebutkan di atas.

Sekarang, pertanyaan lanjutan yang jelas adalah _"mengapa Anda tidak dapat memiliki satu koneksi yang ditinggikan di tab di sebelah koneksi yang tidak ditinggikan?"_ Di sinilah @sba923 harus membaca (:senyum :). Saya mungkin akan membahas beberapa hal yang Anda (@robomac) sudah tahu.

[2] Ketika Anda memiliki dua jendela pada desktop yang sama di stasiun jendela yang sama, mereka dapat berkomunikasi satu sama lain. Saya dapat menggunakan SendKeys dengan mudah melalui WScript.Shell untuk mengirim input keyboard ke jendela mana pun yang dapat dilihat oleh shell.

Menjalankan proses meningkatkan _severs_ koneksi itu. Shell tidak dapat melihat jendela yang ditinggikan. Tidak ada program lain pada tingkat integritas yang sama seperti shell yang dapat melihat jendela yang ditinggikan. Bahkan jika ia memiliki pegangan jendelanya, ia tidak dapat benar-benar berinteraksi dengannya. Ini juga mengapa Anda tidak dapat menyeret/melepaskan dari explorer ke notepad jika notepad berjalan ditinggikan. Hanya proses tinggi lainnya yang dapat berinteraksi dengan jendela tinggi lainnya.

Fitur "keamanan" itu (sebut saja sesuka Anda, itu mungkin dimaksudkan sebagai fitur keamanan pada satu titik) hanya ada untuk beberapa jenis objek sesi-global. Jendela adalah salah satunya. Pipa sebenarnya bukan salah satunya.

Karena itu, sepele untuk merusak keamanan itu. Ambil terminal sebagai contoh. Jika kita memulai koneksi yang ditinggikan dan menyimpannya di jendela _non-elevated_, kita tiba-tiba membuat saluran melalui batas keamanan itu. Hal yang ditinggikan di ujung yang lain bukanlah jendela, itu hanya aplikasi mode teks. Itu segera melakukan penawaran dari tuan rumah yang tidak ditinggikan.

Siapa saja yang dapat _mengontrol_ host non-elevasi (seperti WScript.Shell::SendKeys ) _also_ mendapatkan saluran instan melalui batas elevasi. Tiba-tiba, aplikasi berintegritas sedang apa pun di sistem Anda dapat mengontrol proses berintegritas tinggi. Ini bisa jadi browser Anda, atau penambang bitcoin yang diinstal dengan paket left-pad dari NPM, atau banyak hal lainnya.

Ini adalah risiko kecil, tetapi _adalah_ risiko.

Platform lain telah menerima risiko itu dengan mengutamakan kenyamanan pengguna. Mereka tidak salah untuk melakukannya, tetapi saya pikir Microsoft mendapat lebih sedikit "pass" pada hal-hal seperti "menerima risiko untuk kenyamanan pengguna". Windows 9x adalah bencana keamanan yang tak tanggung-tanggung, dan akun pengguna yang terbatas serta permintaan elevasi dan keamanan tingkat kernel untuk manajemen jendela adalah jawaban untuk hal-hal tersebut. Mereka bukan kunci yang bisa dilonggarkan dengan mudah.

@DHowett-MSFT Terima kasih banyak atas klarifikasinya. Saya pikir kita harus terbiasa menjalankan satu instance Terminal Windows yang ditinggikan dan satu instance yang tidak ditinggikan secara berdampingan, seperti yang kita lakukan dengan aplikasi konsol akhir-akhir ini.

Memukau. Terima kasih. Terminal lebih merupakan penyaji koneksi daripada jendela memang masuk akal. Apakah itu memberi PowerShell, yang sudah lebih fokus pada pipa/koneksi, kontrol tambahan apa pun sebelumnya di konsol berjendela?

Apakah sesi Terminal terpisah sepenuhnya terisolasi satu sama lain?

Saya akan sepenuhnya puas dengan hanya memiliki indikasi bahwa saya berada dalam sesi yang lebih tinggi. Seperti "Administrator: \ Saya sangat merindukan hal itu sekarang.

???

"Jalankan sebagai pengguna yang berbeda" adalah hal yang dibutuhkan semua admin windows! Ini akan sangat membantu jika tersedia. Pilihan terbaik adalah memilikinya dengan bendera di konfigurasi untuk setiap profil.

BTW, berbicara tentang isolasi jendela, izinkan saya mengutip laporan kerentanan ctfmon terbaru

Serangan yang jelas adalah pengguna yang tidak memiliki hak istimewa yang menyuntikkan perintah ke sesi konsol Administrator, atau membaca kata sandi saat pengguna masuk. Bahkan proses AppContainer yang dikotak pasir dapat melakukan serangan yang sama.

@ecki Itu berita yang cukup mengganggu. Aku yakin Tavis tidak akan berpesta malam ini setelah itu.

@DHDHowett-MSFT
Seperti yang telah ditulis banyak orang di sini, jika terminal baru tidak dapat memulai dengan opsi "jalankan sebagai pengguna yang berbeda" daripada untuk sejumlah besar pengguna, itu tidak terlalu berguna, juga tidak kompatibel dengan "model tingkat administratif Active Directory" Microsoft. jika Anda misalnya memiliki pengguna AD dengan hak default, dan menjalankan Skrip PS dengan Adminuser pada pengontrol domain.

Saya tidak memiliki banyak kasus di mana saya memulai terminal dengan pengguna yang saat ini masuk… jadi saya bertanya kepada Anda, apa gunanya Terminal ini? Ping, nslookup dll,.. jika itu niatnya mengapa Anda melakukan begitu banyak pekerjaan untuk semua ini?

Dengan "jalankan sebagai Administrator" Anda memiliki beberapa poin yang valid, tetapi mengapa Konsol lain seperti (PS6/7) masih mendukung fungsi-fungsi ini, jika itu tidak aman?

Saya selalu berpikir Aplikasi Terminal baru akan menggantikan semua jendela cmd/PS/… yang terpisah, tetapi karena tampaknya tidak dapat digunakan di banyak skenario dunia nyata. Ini agak sedih tbh...

@Fisico pengalaman Anda tidak universal, dan saya mendorong Anda untuk mempertimbangkannya ketika meminta seseorang untuk membenarkan keberadaan proyek mereka.

Untuk poin menyeluruh Anda tentang "jalankan sebagai pengguna yang berbeda" tidak ada/tidak berfungsi: itu adalah batasan platform yang kami coba singkirkan. Bukan karena kedengkian atau ketidakmampuan kami tidak mendukungnya.

Adapun mengapa aplikasi konsol lain _do_ mendukungnya, itu tidak aman ketika mereka melakukannya karena mereka secara khusus tidak menghosting tingkat ketinggian yang berbeda di jendela yang sama. Itulah masalah inti di sini. Karena mereka di-host dalam proses mandiri dengan jendela mandiri, mereka bebas dari pembatasan manipulasi tingkat integritas silang.

@DHowett-MSFT
Maaf jika saya menyinggung Anda dengan posting saya, itu bukan niat saya, saya memasukkan terlalu banyak emosi ke dalamnya.
Saya pikir Terminal adalah ide yang bagus dan memiliki potensi yang sangat besar dan saya senang Anda mengembangkannya bersama komunitas untuk mendapatkan hasil maksimal darinya.

Pada titik ini ada begitu banyak kebingungan tentang apa yang diterapkan dan apa yang tidak.
"Jalankan sebagai Administrator" untuk seluruh aplikasi berfungsi saat ini, apakah ini akan tetap ada?

Seperti yang saya pahami, "Jalankan sebagai Administrator" untuk setiap tab/profil bukanlah sesuatu yang ingin Anda terapkan. Saya pikir ini ok untuk kebanyakan dari kita.

"Jalankan sebagai pengguna yang berbeda" tidak mungkin karena Windows tidak mendukungnya untuk aplikasi, dan Anda/kami harus menunggu hingga Windows mendukungnya? Jika demikian, apakah kita berbicara tentang tahun?

"Jalankan sebagai pengguna yang berbeda" per tab/profil juga merupakan sesuatu yang tidak ingin Anda terapkan?

@DHDHowett-MSFT
Seperti yang telah ditulis banyak orang di sini, jika terminal baru tidak dapat memulai dengan opsi "jalankan sebagai pengguna yang berbeda"
daripada untuk sejumlah besar pengguna itu tidak terlalu berguna, ... Saya selalu berpikir Aplikasi Terminal baru akan
ganti semua jendela cmd/PS/… yang terpisah, tetapi sepertinya itu tidak dapat digunakan di banyak skenario dunia nyata. Ini agak sedih tbh...

Saya tidak setuju. Ini adalah kemajuan besar dari apa yang kami miliki sebelumnya. Sayangnya, sebagian besar dari kita mungkin sudah terbiasa menjalankan cangkang kita lebih tinggi karena kurangnya pendekatan yang lebih terperinci ... dan kita masih bisa. Kami tidak bisa _mix_ mereka... tapi kami tidak pernah melakukannya. Serius, di _tiga perusahaan terakhir_ tempat saya bekerja, Wiki Pengembang telah melakukan semua pembuatan/pengujian dalam prompt VS yang ditinggikan. Kami menerapkan keamanan melalui pemindaian waktu nyata, firewall aktif yang agresif, dan mengetahui bahwa pengembang kami jarang melakukan kesalahan. _non-pengembang_ tidak pernah berjalan tinggi, karena (1) kita tidak bisa mempercayai mereka dan (2) mereka tidak perlu.

Jadi saya, misalnya, menghargai Terminal baru ini. Ini tidak sempurna, tetapi juga Take Command / TCC. Setidaknya ini standar.

@DHDHowett-MSFT
Seperti yang telah ditulis banyak orang di sini, jika terminal baru tidak dapat memulai dengan opsi "jalankan sebagai pengguna yang berbeda"
daripada untuk sejumlah besar pengguna itu tidak terlalu berguna, ... Saya selalu berpikir Aplikasi Terminal baru akan
ganti semua jendela cmd/PS/… yang terpisah, tetapi sepertinya itu tidak dapat digunakan di banyak skenario dunia nyata. Ini agak sedih tbh...

Saya tidak setuju. Ini adalah kemajuan besar dari apa yang kami miliki sebelumnya. Sayangnya, sebagian besar dari kita mungkin sudah terbiasa menjalankan cangkang kita lebih tinggi karena kurangnya pendekatan yang lebih terperinci ... dan kita masih bisa. Kami tidak bisa _mix_ mereka... tapi kami tidak pernah melakukannya. Serius, di _tiga perusahaan terakhir_ tempat saya bekerja, Wiki Pengembang telah melakukan semua pembuatan/pengujian dalam prompt VS yang ditinggikan. Kami menerapkan keamanan melalui pemindaian waktu nyata, firewall aktif yang agresif, dan mengetahui bahwa pengembang kami jarang melakukan kesalahan. _non-pengembang_ tidak pernah berjalan tinggi, karena (1) kita tidak bisa mempercayai mereka dan (2) mereka tidak perlu.

Jadi saya, misalnya, menghargai Terminal baru ini. Ini tidak sempurna, tetapi juga Take Command / TCC. Setidaknya ini standar.

ditinggikan != dijalankan sebagai pengguna yang berbeda.
Saya menjalankan PowerShell lebih banyak dengan pengguna AD lain, kemudian dengan pengguna saya sendiri.
Saya dengan Anda bahwa Anda sering menjalankan cmd atau PS sebagai admin meskipun tidak harus, tetapi ada banyak kasus di mana Anda harus menjalankannya sebagai admin. Sebagian besar tugas sysadmin memerlukan hak admin atau pengguna yang berbeda dengan semacam hak istimewa.
Tentu jika Anda perlu menjalankan cmd dalam konteks pengguna, semuanya baik-baik saja.

Saya mengerti bahwa "ditinggikan != dijalankan sebagai pengguna yang berbeda". Saya hanya tidak percaya "jalankan sebagai pengguna yang berbeda" hampir biasa seperti yang Anda klaim.

Saya mengerti bahwa "ditinggikan != dijalankan sebagai pengguna yang berbeda". Saya hanya tidak percaya "jalankan sebagai pengguna yang berbeda" hampir biasa seperti yang Anda klaim.

Jika Anda memiliki sesuatu untuk dilakukan dengan alam semesta Microsoft maka Anda benar-benar membutuhkannya.
Ini bukan ide terbaik untuk login ke mesin windows dengan hak admin domain misalnya.
Menjalankan skrip PS dengan pengguna yang memiliki hak domainadmin atau hak lainnya sangat umum.

@Fisico mengapa tidak menggunakan perintah New-PSSession ?

Skrip otomatis yang memerlukan beberapa jenis elevasi khusus untuk suatu layanan biasanya memerlukan 'jalankan sebagai pengguna yang berbeda'. Apakah itu berlaku untuk Terminal adalah cerita yang berbeda. Anda selalu dapat mengubah login Anda sekali dalam sesi CMD atau PS menggunakan perintah runas . Ini tidak akan mengubah status elevasi tab karena menggunakan login yang mendasarinya, yang merupakan pengguna biasa Anda. Juga skrip apa pun yang Anda jalankan menggunakan Penjadwal Tugas atau pekerjaan cron tidak akan memerlukan Terminal untuk dijalankan kecuali Anda menggunakannya untuk mendapatkan fungsionalitas yang entah bagaimana tidak ada di sesi konsol normal. Jika demikian, pemanfaatan parameter untuk menjalankan skrip tersebut dengan Terminal, yang diluncurkan sebagai proses latar belakang akan menjadi solusinya.

Oleh karena itu elevasi campuran untuk tab tidak diperlukan. Kami memiliki solusi dan cukup mudah untuk menyalin perintah runas tertentu yang Anda perlukan ke file txt yang dapat Anda salin/tempel ke Terminal dan kemudian isi kata sandi Anda (Anda tidak boleh menyimpan kata sandi Anda ke apa pun yang tidak terenkripsi).

@SamuelEnglard
saya tidak ingin terhubung ke Host jarak jauh, untuk menjalankan skrip.

@WSLUser ya itu adalah opsi untuk menggunakan runas, tetapi jauh lebih nyaman untuk menjalankan terminal atau PS sebagai pengguna yang berbeda. Saya tidak mengerti mengapa ini harus menjadi masalah.

@Fisico New-PSSession tidak perlu terhubung ke komputer jarak jauh, lihat entri sintaks pertama kedua .

@SamuelEnglard
saya tidak ingin terhubung ke Host jarak jauh, untuk menjalankan skrip.

@WSLUser ya itu adalah opsi untuk menggunakan runas, tetapi jauh lebih nyaman untuk menjalankan terminal atau PS sebagai pengguna yang berbeda. Saya tidak mengerti mengapa ini harus menjadi masalah.

Ini adalah operasi yang cukup standar bagi pengguna untuk menyematkan PowerShell ke bilah tugas dan Klik Kanan untuk dijalankan sebagai Admin atau di beberapa lingkungan RunAs OtherUser sebagai akun yang ditinggikan diperlukan untuk menjalankan dan skrip tingkat perusahaan. Mengatakan tidak mungkin untuk terminal seperti lingkungan yang memanfaatkan PSLockDown dan memaksa RunAs Admin hanya untuk memuat shell atau VSCode
Menurut opini saya

Jika Anda benar-benar perlu menjalankan tab sebagai pengguna yang berbeda, Anda dapat memiliki profil yang menjalankan New-PSSession -Credential | Enter-PSSession di awal.

PENOLAKAN : Saya tidak bertanggung jawab atas komputer yang rusak karena melakukan ini.

Jika Anda benar-benar perlu menjalankan tab sebagai pengguna yang berbeda, Anda dapat memiliki profil yang menjalankan New-PSSession -Credential | Enter-PSSession di awal.

> DISCLAIMER : Saya tidak bertanggung jawab atas komputer yang rusak karena melakukan hal ini.

Tentu, atau "keamanan" yang berdiri di sini dapat dipertimbangkan kembali. Sekali lagi, saya menyematkan PowerShell ke bilah Tugas saya, dari sana saya dapat meluncurkan PowerShell non-elevated; Saya dapat mengklik kanan itu dan memilih "Run As Administrator" dan jika di lingkungan corp saya dapat Klik kanan pada ikon, lalu Shift-Klik Kanan pada "Windows PowerShell" dan pilih "Run as Different User" untuk meluncurkan PowerShell dengan kredensial alternatif. Tidak ada sesi, tidak ada RDP'ing ke host lain untuk mendapatkan kredit tersebut.

Tentu, atau "keamanan" yang berdiri di sini dapat dipertimbangkan kembali. Sekali lagi, saya menyematkan PowerShell ke bilah Tugas saya, dari sana saya dapat meluncurkan PowerShell non-elevated; Saya dapat mengklik kanan itu dan memilih "Run As Administrator" dan jika di lingkungan corp saya dapat Klik kanan pada ikon, lalu Shift-Klik Kanan pada "Windows PowerShell" dan pilih "Run as Different User" untuk meluncurkan PowerShell dengan kredensial alternatif. Tidak ada sesi, tidak ada RDP'ing ke host lain untuk mendapatkan kredit tersebut.

Ya, dan saya juga bisa melakukannya dengan Terminal Windows. Sepakat. Saya tidak melihat bagaimana itu membantu mereka yang ingin memiliki campuran tab yang berjalan sebagai pengguna yang berbeda (atau ketinggian yang berbeda).

Selain "tab campuran", saya hanya ingin mengklarifikasi, Anda TIDAK BISA melakukannya dengan (pratinjau yang dirilis) Terminal Windows karena desain aplikasi Windows Store. Anda hanya dapat menjalankan sebagai pengguna yang menginstal aplikasi itu dan masuk sebagai pengguna yang sama.

Yang saya inginkan hanyalah dapat melakukan apa yang saya lakukan hari ini, masuk ke PC sebagai pengguna biasa dan menjalankan shell yang ditinggikan. Jika Terminal Windows dirilis apa adanya, itu tidak berguna bagi saya.

Poin yang sangat bagus. Batasan ini tidak ada dengan versi pribadi (non-toko) dari Terminal Windows.

Selain "tab campuran", saya hanya ingin mengklarifikasi, Anda TIDAK BISA melakukannya dengan (pratinjau yang dirilis) Terminal Windows karena desain aplikasi Windows Store. Anda hanya dapat menjalankan sebagai pengguna yang menginstal aplikasi itu dan masuk sebagai pengguna yang sama.

Yang saya inginkan hanyalah dapat melakukan apa yang saya lakukan hari ini, masuk ke PC sebagai pengguna biasa dan menjalankan shell yang ditinggikan. Jika Terminal Windows dirilis apa adanya, itu tidak berguna bagi saya.

Saya baru saja membuka 2 contoh toko build Terminal Windows - satu ditinggikan, dan satu tidak. Jadi saya tidak tahu mengapa itu tidak bekerja untuk Anda.

Ok, saya harus percaya Anda adalah admin lokal di PC Anda. Untuk lebih jelasnya, mungkin saya harus mengklarifikasi. Saya tidak pernah menjadi admin lokal di workstation saya. Jadi ketika saya pergi ke 'jalankan sebagai admin' saya diminta untuk pengguna/kata sandi.

Akun 'admin' yang saya gunakan berbeda dari akun malware/pembaca email biasa saya. Jadi secara teknis yang saya lakukan adalah dijalankan sebagai pengguna yang berbeda. Ini adalah batasan aplikasi Windows Store. Solusinya (dan mungkin mereka akan melakukan ini) adalah dengan merilis ini sebagai komponen Windows yang tidak memiliki batasan tersebut.

* [URGENT] SEMUA SAYA TELAH MENEMUKAN SOLUSI UNTUK MASALAH INI! * *

Dengan mengikuti panduan ini
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
Anda dapat membuat folder aplikasi windows milik Anda sendiri!

setelah Anda selesai melakukannya, Anda dapat menemukan folder Microsoft.WindowsTerminal._blahblahYourVersion_ . Setelah masuk, cari WindowsTerminal.exe Tampil di bawah

Setelah Anda menemukannya, Buat pintasan file ini dan letakkan di mana pun Anda mau. Setelah melakukannya, atur untuk dijalankan sebagai administrator. Anda dapat melakukan ini dengan mengklik kanan dan pergi ke _Properties>Advanced>Run as administrator_ Setelah itu klik oke dan Anda sudah siap!

Secara pribadi saya membutuhkan ini karena saya menggunakan pintasan di bilah tugas saya sehingga saya bisa menekan _Windows+1_ untuk meluncurkannya sebagai admin. Tidak terlalu jauh menavigasi menu mulai saya untuk menjalankannya dengan benar.

Anda juga dapat membuka ritsleting bundel yang kami masukkan di halaman rilis. Itu hanya file ZIP. Harap dicatat, kami _tidak secara resmi mendukung_ eksekusi tanpa paket!

Tapi ini masih berarti tidak ada cara _supported_ untuk berlari lebih tinggi! Saya pikir ini adalah fitur yang harus dimiliki.

Memang, saya berdiri dikoreksi.

Yang _is_ hilang adalah entri "jalankan sebagai administrator" di menu klik kanan pintasan bilah tugas.

Berbicara dengan beberapa orang kemarin di pertemuan dan beberapa orang mengatakan mereka terutama meluncurkan PowerShell dengan Windows+X dan ingin memiliki terminal/terminal sebagai admin di sana.

Poin yang sangat bagus!

Itulah poin saya! Ini adalah solusi untuk menjalankannya dari taskbar
dengan hak istimewa admin!

Pada Minggu, 25 Agustus 2019, 1:08 Stéphane BARIZIEN [email protected]
menulis:

Poin yang sangat bagus!

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Microsoft/Terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX6HJKTDN5WX2JKTDN5W
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

Memang, saya berdiri dikoreksi.

Yang _is_ hilang adalah entri "jalankan sebagai administrator" di menu klik kanan pintasan bilah tugas.

Di bilah tugas, klik kanan dua kali. Sekali pada ikon untuk membuat menu konteks muncul, lalu kedua kalinya pada nama aplikasi. misalnya "Terminal Windows (Pratinjau)" dan pilih "Jalankan sebagai Administrator"

Saya bingung.

memerah.

Malu.

Kenapa aku tidak memikirkan ini?

Terima kasih sudah berbagi dengan kita semua!

Mari kita lihat masalah dari ujung yang lain...
Windows memungkinkan proses yang tidak ditinggikan mengontrol proses yang tidak ditinggikan lainnya, mengirim penekanan tombol, menangkap UI mereka, dll ... tetapi mencegah proses yang tidak ditinggikan melakukan itu ke jendela proses yang ditinggikan.
Terminal Windows dirancang untuk juga digunakan untuk mengelola server jarak jauh, melalui ssh, remote PowerShell, dll...
Ini berarti Terminal Windows menjadi lubang keamanan segera setelah digunakan untuk administrasi, karena malware lokal dapat menunggu sesi Terminal Windows untuk memata-matai apa yang dilakukan pengguna, dan segera setelah mendeteksi shell jarak jauh, coba menyuntikkan perintah untuk menginfeksi server menggunakan hak admin.

Mencegah Terminal Windows agar tidak dijalankan sebagai admin tidak tampak seperti peningkatan keamanan sama sekali, karena menjalankannya sebagai admin akan melindungi pengguna dari proses yang tidak ditinggikan yang membajak sesi shell jarak jauh mereka. Menjalankannya sebagai admin harus direkomendasikan kepada pengguna setiap kali mereka menggunakan alat yang memberi mereka prompt perintah yang ditinggikan, secara lokal atau jarak jauh.

Dan tentang Sudo untuk Windows, bukankah menjalankan layanan sshd dan kemudian menghubungkan ke localhost dari shell yang tidak ditinggikan menunjukkan masalah keamanan yang sama?

Ini berarti Terminal Windows menjadi lubang keamanan segera setelah digunakan untuk administrasi, karena malware lokal dapat menunggu sesi Terminal Windows untuk memata-matai apa yang dilakukan pengguna, dan segera setelah mendeteksi shell jarak jauh, coba menyuntikkan perintah untuk menginfeksi server menggunakan hak admin.

Meskipun benar bahwa sistem jarak jauh dapat terinfeksi (dengan asumsi proses jarak jauh memiliki hak admin), itu tidak berarti kita juga harus membiarkannya menginfeksi sistem lokal juga.

Mencegah Terminal Windows agar tidak dijalankan sebagai admin tidak tampak seperti peningkatan keamanan sama sekali, karena menjalankannya sebagai admin akan melindungi pengguna dari proses yang tidak ditinggikan yang membajak sesi shell jarak jauh mereka. Menjalankannya sebagai admin harus direkomendasikan kepada pengguna setiap kali mereka menggunakan alat yang memberi mereka prompt perintah yang ditinggikan, secara lokal atau jarak jauh.

Tidak ada yang menghentikan Anda menjalankan Terminal Windows dengan hak admin sekarang. Masalah yang dihadapi adalah tentang memiliki tab campuran yang ditinggikan dan tidak ditinggikan.

@SamuelEnglard tepat untuk merespons.

Untuk menambahkan, apa yang kami coba lakukan adalah menghindari menambahkan lubang keamanan _baru_. Konsol asli adalah masalah yang sama dengan manajemen server jarak jauh. Sayangnya tidak ada yang bisa kita lakukan tentang itu. Pengguna yang melakukan manajemen server jarak jauh selalu menjalankan konsol/terminal mereka lebih tinggi, dan itu akan memberi mereka keamanan tambahan (meskipun saya bukan ahli keamanan dan saya tidak akan menafsirkan pernyataan itu sebagai saran)

Gagasan untuk kemajuan dalam masalah ini: Coba jalankan seluruh _app_ sebagai yang ditinggikan, dan jika berhasil, tambahkan tombol di sebelah setiap tombol "buka" dengan ikon pelindung UAC, dan tambahkan ikatan kunci awalan untuk membuka tab yang ditinggikan: Ctrl Shift E . (Saya memeriksa dan ini tidak terikat.) Ini hanya berfungsi untuk tab berikutnya yang terbuka.

Bagaimanapun, tab yang dibuka memiliki ikon UAC sebelum ikon regulernya, dan dijalankan sebagai administrator. (Ingat, program tidak dapat mengirim kunci ini lagi. Kami menjalankan aplikasi sebagai administrator.)

Aplikasi harus mencoba meningkatkan otomatis, dan jika gagal, jalankan secara normal, dan abaikan seluruh utas ini.

Memang, saya berdiri dikoreksi.
Yang _is_ hilang adalah entri "jalankan sebagai administrator" di menu klik kanan pintasan bilah tugas.

Di bilah tugas, klik kanan dua kali. Sekali pada ikon untuk membuat menu konteks muncul, lalu kedua kalinya pada nama aplikasi. misalnya "Terminal Windows (Pratinjau)" dan pilih "Jalankan sebagai Administrator"

Baru saja diperhatikan bahwa UAC Prompt yang didapat dalam kasus itu mengatakan "Program tidak dikenal."

Agak tak terduga jika Anda bertanya kepada saya ...

@sba923 itu #2289 :senyum:

@DHowett-MSFT terima kasih atas infonya; baik untuk mengetahui bahwa (sudah) dilacak.

Jawaban terbaik untuk ini yang dapat saya pikirkan adalah memiliki opsi untuk memiliki profil yang harus ditinggikan dan jika jendela saat ini tidak ditinggikan, mulai contoh baru yang ditinggikan dengan profil itu. (Pikirkan bagaimana sesi penjelajahan pribadi bekerja)

Ide yang sangat bagus

Saya menggunakan cara ini untuk menambahkan Terminal di menu Win+X:
Buat pintasan baru dengan target:
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!App
edit:
Maaf, ini tidak akan berfungsi jika Anda ingin menjalankan Aplikasi sebagai Admin.
Sebagai gantinya, Anda dapat menggunakan nircmd dan membuat pintasan dengan
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(path yang benar untuk "Microsoft.WindowsTerminal_xxxxxxxxxxxx" dapat diketahui dengan perintah PS "Get-appxpackage *WindowsTerminal*", gunakan entri di PackageFamilyName)

Pintasan ini dapat digunakan untuk memulai terminal dengan hak administrator dengan klik dua kali sederhana dan dengan WinXEditor dapat ditambahkan di menu Win+X.
Catatan: Terminal harus juga diinstal di akun administrator.

Apakah ide untuk memuat setiap profil sebagai Administrator atau hanya yang tertentu? Idealnya saya ingin memilikinya dengan profil individu. Mungkin properti yang merupakan akun "runas" dan satu lagi sebagai "ditingkatkan"?

Seperti yang dibahas panjang lebar di utas ini, Anda tidak dapat memiliki campuran yang ditinggikan dan tidak ditinggikan dalam contoh Terminal Windows yang sama, dan ini tidak akan ditambahkan.

Memang, saya berdiri dikoreksi.
Yang _is_ hilang adalah entri "jalankan sebagai administrator" di menu klik kanan pintasan bilah tugas.

Di bilah tugas, klik kanan dua kali. Sekali pada ikon untuk membuat menu konteks muncul, lalu kedua kalinya pada nama aplikasi. misalnya "Terminal Windows (Pratinjau)" dan pilih "Jalankan sebagai Administrator"

FWIW, saya baru saja menguji shift-and-klik kanan yang memberikan opsi "Jalankan sebagai administrator" segera - hanya sedikit lebih cepat daripada dua opsi klik kanan yang sebelumnya menjadi pilihan saya.

Hai teman-teman apakah Anda lupa UAC? Aplikasi tidak dapat mengklik sesuatu di desktop yang aman.

FWIW, saya baru saja menguji shift-and-klik kanan yang memberikan opsi "Jalankan sebagai administrator" segera - hanya sedikit lebih cepat daripada dua opsi klik kanan yang sebelumnya menjadi pilihan saya.

Anda juga dapat ctrl + shift + klik kiri pada ikon untuk membuka UAC secara instan.

Hebat, terima kasih banyak! Berapa banyak jalan pintas yang harus kita ingat? ;-)

Untuk poin menyeluruh Anda tentang "jalankan sebagai pengguna yang berbeda" tidak ada/tidak berfungsi: itu adalah batasan platform yang kami coba singkirkan. Bukan karena kedengkian atau ketidakmampuan kami tidak mendukungnya.

Adapun mengapa aplikasi konsol lain _do_ mendukungnya, itu tidak aman ketika mereka melakukannya karena mereka secara khusus tidak menghosting tingkat ketinggian yang berbeda di jendela yang sama. Itulah masalah inti di sini. Karena mereka di-host dalam proses mandiri dengan jendela mandiri, mereka bebas dari pembatasan manipulasi tingkat integritas silang.

Pasti berharap berjalan sebagai pengguna yang berbeda adalah sesuatu yang datang di beberapa titik. Meskipun bukan sebagian besar aktivitas saya sehari-hari, beberapa cmdlet PowerShell memerlukan peningkatan (dan saya menjalankan dengan pengguna yang berbeda, anggaplah admin pengguna yang dilindungi).

Ini bukan akhir dari dunia, tetapi pasti akan menjengkelkan harus kembali ke cangkang warisan.

Pada waktunya, kurasa!

Sama sekali tidak ada masalah / batasan dengan menggunakan Terminal Windows yang ditinggikan, jadi tidak perlu tetap menggunakan "cangkang lama" (atau lebih tepatnya: ke host konsol lawas).

Hanya saja Anda tidak dapat mencampur yang ditinggikan dan yang tidak ditinggikan di (tab berbeda di dalam) instance yang sama .

Sama sekali tidak ada masalah / batasan dengan menggunakan Terminal Windows yang ditinggikan, jadi tidak perlu tetap menggunakan "cangkang lama" (atau lebih tepatnya: ke host konsol lawas).

Hanya saja Anda tidak dapat mencampur yang ditinggikan dan yang tidak ditinggikan di (tab berbeda di dalam) instance yang sama .

Saya kira saya mungkin salah mengartikan hal di atas, tetapi ada batasan platform dengan menjalankan terminal di bawah konteks pengguna yang berbeda sama sekali dari apa yang saya baca.

Saya kira saya mungkin salah mengartikan hal di atas, tetapi ada batasan platform dengan menjalankan terminal di bawah konteks pengguna yang berbeda sama sekali dari apa yang saya baca.

Yah, utas ini telah ada di seluruh papan pada saat itu. Saya bukan admin di stasiun kerja saya, jadi 'jalankan sebagai admin' hanya meminta saya untuk memasukkan 'kredit tinggi' saya.

Kita mungkin harus memiliki utas baru tentang kasus penggunaan itu.

Untuk lebih jelasnya, yang saya maksud (dan saya pikir banyak 'admin' perlu) adalah kemampuan untuk login ke workstation kami sebagai pengguna biasa. Kemudian jalankan 'beberapa shell' sebagai pengguna yang ditinggikan seperti pada Admin Domain untuk melakukan pekerjaan AD.

Benar atau salah, itulah yang sebagian dari kita lakukan dan butuhkan. Semua trik tentang menginstal Konsol dari toko sebagai pengguna itu dan merancang pintasan pintar tidak terlalu berhasil untuk saya.

Dan ya, saya dapat melakukan ini dalam beberapa cara dan mungkin saya harus membatasi beberapa aktivitas ini ke stasiun kerja yang dilindungi tetapi kenyataannya adalah, sebagai pengguna normal, saya tidak memerlukan shell secara umum.

IMVHO kebingungan berasal dari fakta bahwa orang-orang (memegang kebiasaan pra-Vista sekarat keras) kurang lebih secara bergantian menggunakan istilah "ditinggikan" dan "sebagai pengguna [domain] [admin] lainnya."

Menjalankan sebagai pengguna lain tidak sama dengan menjalankan yang ditinggikan.

1. Beberapa orang di utas ini memiliki kebutuhan, ketika masuk sebagai pengguna admin, untuk menjalankan beban kerja Terminal Windows dengan elevasi.

2. Beberapa orang lain memiliki kebutuhan, ketika masuk sebagai pengguna normal (atau non-domain-admin), untuk menjalankan beban kerja Terminal Windows sebagai pengguna admin lainnya, biasanya dengan elevasi.

3. Seseorang juga dapat mempertimbangkan kasus di mana orang masuk sebagai pengguna A normal dan ingin menjalankan beban kerja Terminal Windows sebagai pengguna B tanpa peningkatan.

Di #2 dan #3, penyebaran berbasis Windows Store membuat cerita lebih kompleks, karena Terminal Windows tidak akan berjalan sebagai pengguna yang masuk, di mana "aplikasi toko" disebarkan untuk pengguna tersebut.

Semoga saya memahami situasinya dengan benar. Jika saya melakukannya, saya harap ini menjelaskan masalah ini sedikit.

Anda melakukannya dengan benar.

Sekadar informasi, masalah persis itu, tidak dapat meningkatkan ("Jalankan Sebagai Administrator", sebagai lawan berjalan sebagai pengguna administratif lain, "Jalankan Sebagai Pengguna Berbeda") ketika akun yang Anda masuki bukan administrator lokal pada sistem, sesuai praktik terbaik), secara singkat dibahas dalam masalah lain: https://github.com/microsoft/terminal/issues/1538 . Itu ditutup dengan penjelasan bahwa itu adalah masalah Windows, bukan masalah Terminal, karena tampaknya merupakan batasan aplikasi Store.

Tanpa memperdebatkan apakah ini seharusnya dirilis sebagai instalasi MSI alih-alih menggunakan Store, ada solusi di utas yang saya gunakan; masuk sebentar sebagai akun admin Anda, instal aplikasi dari Store, lalu keluar lagi. Jalankan Sebagai Administrator kemudian berfungsi untuk akun pengguna normal saya (sampai pembaruan berikutnya, ketika itu harus dilakukan lagi).

Ya harus ada MSI yang tersedia. Majikan baru saya melarang pemasangan Toko (publik), jadi satu-satunya cara saya dapat menggunakan Terminal Windows adalah dengan membangun dari sumber...

Kecewa melihat Anda tidak dapat menjalankan Terminal Windows "sebagai administrator" tanpa kesalahan dan kemudian harus menerapkan solusi. Saya akan mengatakan banyak perusahaan menerapkan pendekatan pemisahan hak istimewa untuk identitas (dengan karyawan ICT memiliki akun istimewa dan tidak istimewa). Jadi, dapat mengakomodasi persyaratan ini dengan menyediakan penyebaran MSI opsional sesuai saran @ sba923 akan menjadi pendekatan yang rapi sampai aplikasi yang dibundel toko waktu tersebut dapat mengatasi pemisahan hak istimewa?

Ini adalah PREVIEW bahkan bukan rilis 1.0...

Saya merasa topik ini telah dibahas dengan cukup baik pada saat ini, tetapi ada satu perspektif yang belum saya pahami: mengapa kita tidak dapat membuat pintasan Windows ke aplikasi ini? Itulah solusi umum untuk "selalu luncurkan sebagai administrator" - solusi tipikal adalah membuat pintasan dan mengubah pintasan untuk menggunakan akses tinggi sebagai default.

Dapatkah seseorang tolong jelaskan kepada saya mengapa kami tidak dapat membuat pintasan ke aplikasi ini? Ini mungkin lebih terkait dengan cara kerja bagian dalam Windows daripada cara kerja bagian dalam Terminal, tetapi saya merasa kita sedang berbelit-belit jika saya tidak menanyakannya secara langsung.

Terima kasih.

Saya menyimpan nircmd di folder c:\utils saya bersama dengan banyak alat lain yang umum digunakan.
Saya menambahkan profil yang terlihat seperti ini:

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

Ini menampilkan permintaan elevasi UAC, lalu membuka instance admin Terminal Windows. Ini adalah solusi yang layak untuk saat ini.

Saya akan baik-baik saja dengan kemampuan untuk menandai sesi sebagai Ditinggikan dan membukanya di jendela baru, jujur.

Saya datang ke sini mencari solusi yang rapi tetapi karena tampaknya tidak ada, jadi saya hanya akan membagikan solusi hacky-ish saya. Saya menambahkan profil untuk menjalankan PowerShell yang ditinggikan:

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

Itu muncul di jendela terpisah tetapi menyelesaikan pekerjaan.

Saya merasa topik ini telah dibahas dengan cukup baik pada saat ini, tetapi ada satu perspektif yang belum saya pahami: mengapa kita tidak dapat membuat pintasan Windows ke aplikasi ini? Itulah solusi umum untuk "selalu luncurkan sebagai administrator" - solusi tipikal adalah membuat pintasan dan mengubah pintasan untuk menggunakan akses tinggi sebagai default.

Dapatkah seseorang tolong jelaskan kepada saya mengapa kami tidak dapat membuat pintasan ke aplikasi ini? Ini mungkin lebih terkait dengan cara kerja bagian dalam Windows daripada cara kerja bagian dalam Terminal, tetapi saya merasa kita sedang berbelit-belit jika saya tidak menanyakannya secara langsung.

Terima kasih.

@aaronsteers , Anda benar bahwa ini lebih tentang Windows daripada tentang Terminal. Masalah utama di sini adalah bahwa kami didistribusikan dan diinstal sebagai "paket aplikasi modern." Mereka memiliki sejumlah batasan dan batasan yang tidak disengaja dibandingkan dengan aplikasi asli, tetapi itu diperlukan untuk Terminal karena itu juga cara yang paling sulit untuk menggunakan komponen "Windows API modern" (WinRT). Ini sangat membuat frustrasi semua orang di tim hampir sepanjang waktu. :senyum:

Kami mencoba mengubah frustrasi itu, dan frustrasi komunitas, menjadi kemajuan untuk platform. Saya akan minta maaf, meskipun, perubahan itu tidak cepat di sini di Windows!

@DHowett Saya benar-benar mencoba untuk mengerti, karena saya 2/3 suka Terminal, tetapi tidak melakukan beberapa dasar yang biasa saya lakukan dengan TakeCommand atau ConEmu, dll.

Saya tidak dapat mencampur ketinggian di berbagai tab. Jika saya mengerti, itu karena Anda adalah jenis aplikasi yang berbeda dan tidak benar-benar menghosting shell?

Buffer scrollback tidak pernah dibersihkan, di salah satu dari tiga lingkungan (cmd, PowerShell, wsl bash.) Itu terjadi di shell normal saya. Sekali lagi, karena cara hostingnya?

Dan akan sangat menyenangkan jika konteks atau menu drop-down lebih mudah diakses. Misalnya, untuk menghapus scrollback itu, mengingat bahkan trik melarikan diri konsol tidak berfungsi untuk saya.

Integrasi lingkungan, dan seberapa baik ia mengambil shell WSL Linux, sangat bagus. Tapi itu menghabiskan banyak kegunaan melalui masalah elevasi dan scrollback, jadi saya jarang menggunakannya.

@robomac Ada posting bagus oleh @DHowett-MSFT di sini yang menjelaskan mengapa kami tidak dapat menggabungkan tab yang ditinggikan dan tidak ditinggikan di jendela yang tidak ditinggikan yang sama.

tl; dr adalah: Jika kami mengizinkan pengguna untuk terhubung ke baris perintah yang ditinggikan dari jendela Terminal yang tidak ditinggikan, maka itu menciptakan lubang keamanan raksasa, di mana aplikasi lain yang tidak ditinggikan dapat secara efektif mendorong proses yang ditinggikan, melalui jendela Terminal.

Saya tidak tahu bagaimana ConEmu mengurangi risiko ini, jika mereka melakukannya. Sangat mungkin bahwa itu adalah lubang keamanan yang dibuat oleh conemu yang tidak nyaman kami kirim sebagai bagian dari Terminal Windows.

Kekhawatiran Anda lainnya adalah semua masalah yang dilacak di tempat lain dalam repo ini, saya sarankan mencari mereka untuk melacak kemajuan mereka satu per satu. Kami lebih suka menyimpan utas ini pada satu topik "ketinggian tab yang beragam"/"memiliki profil yang diluncurkan lebih tinggi"

Tentang topik: Saya ingin bereksperimen dengan rute "luncurkan instance lain yang ditinggikan" untuk profil "ditinggikan". Jika pengalaman pengguna tidak terlalu buruk, maka itu kemungkinan rute ke depan di sini, setidaknya sebagai opsi.

ConEmu tidak mengurangi risiko ini. Mereka meneruskan risiko itu ke penggunanya. (Saya bahkan tidak yakin mereka mendokumentasikan risiko ini.)

Pada topik "luncurkan instance lain yang ditingkatkan": Saya tidak akan keberatan dengan perilaku ini selama itu dapat menggunakan instance Terminal yang sama yang ditinggikan untuk tab ini dan tidak meluncurkan instance baru setiap kali saya memanggil profil "ditinggikan".

Menurut pendapat saya, "raksasa" lubang keamanan itu agak berlebihan. Tidaklah normal untuk memiliki malware di komputer seseorang yang duduk dan menunggu kesempatan untuk meningkat, sehingga mengorbankan kenyamanan demi keamanan tidak terasa benar.

Di sisi lain, jika tujuan akhirnya adalah agar WT dikirimkan dengan Windows sebagai terminal default, itu akan meningkatkan permukaan serangan secara dramatis. Tetapi sekali lagi, dalam kasus ini, saya pribadi akan mengurangi risiko dengan menggunakan alternatif yang tidak populer yang tidak mungkin menjadi target serangan semacam itu dan memberikan kenyamanan yang diperlukan (dengan asumsi mendeteksi keberadaan tab yang ditinggikan di terminal tidak cukup sepele. menjadi spesifik terminal).

Beberapa di antaranya adalah tl;dr bagi saya, tetapi jika Anda mengambil dan membuang paket, Anda dapat menjalankan wt di luar sandboxing, artinya elevasi, dan dijalankan saat pengguna yang berbeda bekerja tanpa masalah. Saya telah berbicara dengan MSFT tentang hal ini dan diberitahu untuk mengajukan permintaan tarik, tetapi keterampilan VS saya cukup lemah. Apa yang cukup mudah untuk dilakukan adalah menandatanganinya dengan benar (harus melakukan ini dengan pki internal saya sendiri sehingga saya dapat menjalankannya di applocker) dan meletakkannya dalam format yang dapat didistribusikan MSI atau MSIX. Ada bug aneh di sana-sini yang mungkin spesifik untuk menjalankannya dengan cara ini, tetapi secara keseluruhan itu bekerja dengan sangat baik. Untuk saat ini saya hanya memiliki fungsi untuk mengekstrak, menandatangani, dan mengganti/memperbarui versi berbasis file program dari versi berbasis toko.

Saya memahami risiko fitur "memasukkan" tab yang ditinggikan ke dalam proses yang tidak ditingkatkan, tetapi tidakkah mungkin untuk sebaliknya?
Berarti untuk orang-orang bagaimana membutuhkan ini, biarkan Terminal itu sendiri juga berjalan sebagai Ditinggikan dan memungkinkan untuk memulai Tab yang tidak ditinggikan?
Tentu saja, itu memiliki kelemahan lain, tetapi bagi saya (dan saya pikir untuk orang lain juga) mereka dapat diterima.
(tentu, itu bisa "menarik" karena terminal adalah aplikasi windows store, tidak yakin apakah itu berfungsi)

hal. Maaf untuk membuka kembali masalah ini (juga jika orang lain sudah membuat saran itu dan saya "membaca" itu).

Terima kasih kepada @EmTschi , saya membuat solusi sederhana dan 100% nyaman
Ini menggunakan menu konteks dan bertindak hampir sama seperti yang dilakukan PowerShell 7
https://github.com/nt4f04uNd/wt-contextmenu
Di sana Anda dapat menemukan panduan cara menerapkannya dan semua file yang diperlukan

Terima kasih atas tipnya, saya akan mencobanya nanti.
Saat ini saya sedang bekerja dengan dua pintasan di desktop saya, yang dipetakan ke tombol Ctrl+Alt+T dan Ctrl+Alt+Shift+T untuk terminal yang ditinggikan, itu juga ok sebagai solusi, tapi... tidak sebaik mungkin dan bermil-mil jauhnya dari sesuatu seperti Sudo.

@

Setiap kali saya mencoba menjalankan aplikasi Terminal dengan akun administrator, klik kanan -> jalankan sebagai administrator, UAC muncul dua kali dan terjadi kesalahan yang mengatakan:
"Windows tidak dapat menemukan (path\WindowsTerminal.exe) Pastikan Anda mengetik ...".
Jalur ada dan aplikasi berfungsi dengan benar untuk pengguna non admin yang membuat aplikasi, tetapi pengguna administrator lain tidak dapat menjalankannya.
Jika saya masuk ke pengguna admin, aplikasi terminal tidak ada di pengaturan atau menu mulai, seolah-olah itu tidak pernah diinstal pada sistem.
Apakah ada cara untuk membuat aplikasi agar dapat diinstal untuk semua pengguna? Atau apakah root proyek harus berada di direktori khusus non-pengguna?

Saya melihat masalah yang sama terjadi juga.

Windows versi 18922.1000

Baru saja diinstal pada pembaruan Win10 1909, dan saya memiliki masalah yang sama dengan mencoba menjalankan sebagai Administrator

Masalah yang sama disini. Tidak dapat menggunakan terminal windows sekarang karena saya selalu perlu menjalankan buruh pelabuhan dan kemudian saya selalu perlu menjadi admin di terminal ...

Saya memiliki solusi hack-around untuk siapa saja yang menginginkannya:

1. unduh msixbundle dari halaman rilis
2. unzip itu, di sana, temukan msix yang untuk platform Anda (biasanya yang x64)
3. unzip itu ke folder di suatu tempat
4. salin folder itu di mana pun Anda mau dan jalankan WindowsTerminal.exe yang ditinggikan atau sesuka Anda

Banyak dari kegagalan ini tampaknya berasal dari kenyamanan memiliki ini sebagai aplikasi toko. Ada diskusi tentang ini di #1386 dan seseorang di sana telah menyebutkan mungkin menginstal dengan Scoop, yang mengotomatiskan proses ekstraksi di atas.

Alangkah baiknya jika yang berikut ini diperlakukan sebagai warga negara kelas satu:

1. Instalasi portabel (file zip -- meskipun konfigurasinya belum portabel, karena berada di bawah AppData\Local saat kehabisan area instalasi windows store)
2. Pemasang .exe lama biasa (atau, jika Anda harus, .msi) untuk orang yang tidak menginginkan Store atau menggunakan Store Installer

Keduanya tidak terlalu sulit untuk diterapkan dari prosedur pembuatan saat ini, sebagaimana dibuktikan oleh otomatisasi Scoop. Dan sekarang Terminal Windows menjadi Sangat Bagus, saya ingin dapat menggunakannya seperti halnya terminal lainnya.

Sementara kami melakukannya: kecuali ada ketidakcocokan API, akan sangat bagus jika memiliki opsi untuk menginstal Terminal Windows tanpa Store (bahkan cara "portabel") pada versi Windows 10 yang lebih lama (majikan saya memblokir kami di 1809/ RS5, dan menginstal dari Store diblokir).

@sba923 jika kami tidak bergantung pada API yang hanya ada pada tahun 1903, kami tidak akan memerlukan 1903.

Tentu ... adalah tebakan saya

Harus melobi untuk meningkatkan seluruh perusahaan, mungkin akan menemui jalan buntu. . .

Ini sangat bodoh.

Mari kita buat terminal terpadu baru untuk command prompt, powershell, dan bash untuk windows.
Bisakah saya menjalankan cmd.exe sebagai admin?
Tidak.

Kira saya hanya akan menyimpan ikon cmd.exe dan powershell saya untuk dijalankan sebagai admin di bilah tugas saya tanpa batas waktu.

Hal bodoh seperti inilah mengapa mesin kerja utama saya masih Macbook.

Ini sangat bodoh.

Mari kita buat terminal terpadu baru untuk command prompt, powershell, dan bash untuk windows.
Bisakah saya menjalankan cmd.exe sebagai admin?
Tidak.

Kira saya hanya akan menyimpan ikon cmd.exe dan powershell saya untuk dijalankan sebagai admin di bilah tugas saya tanpa batas waktu.

Hal bodoh seperti inilah mengapa mesin kerja utama saya masih Macbook.

Saya setuju dalam hal ini. Saya ingin satu jendela Terminal Windows yang menampung semua tab terminal yang saya butuhkan, di mana setiap tab terminal dapat menjadi salah satu dari beberapa host terminal yang diinstal, dan ditinggikan atau tidak.

Sepertinya fitur elevasi campuran ini ditahan oleh keputusan desain teknis untuk meng-host semua tab pada satu pegangan HWND.

1) Bisakah Anda menjalankan terminal baru sebagai Admin? YA (Ada masalah melakukannya tergantung pada bagaimana Anda menginstalnya/meluncurkannya tetapi tidak ada keinginan untuk ini tidak berfungsi). (Jika Anda tidak tahu bagaimana melakukan ini, lihat beberapa posting di atas tentang caranya.

2) Bisakah Anda memiliki satu tab dengan peningkatan sementara yang lain tidak? Tidak . Lihat https://github.com/microsoft/terminal/issues/632#issuecomment -519375707 untuk mengetahui alasannya.

Bisakah orang-orang ingat bahwa masalah ini tentang tab elevasi campuran?!? Jika Anda ingin meluncurkan seluruh proses yang ditinggikan dan tidak dapat membuka masalah baru.

@DHowett-MSFT Bisakah kita mengganti nama masalah ini menjadi tentang tab elevasi campuran?

Apa pun cara penanganannya atau tidak, terminal atau tab yang ditinggikan harus memiliki semacam indikator. Sekarang jika saya memulai terminal baru dengan Jalankan sebagai administrator, tidak ada cara untuk dengan mudah melihat tab cmd saya memiliki akses yang lebih tinggi dibandingkan dengan yang ada di jendela berikutnya.

EDIT setelah komentar @SamuelEnglard : Jelas saya buru-buru memilih cmd sebagai contoh yang buruk. Ya, cmd menampilkan 'Administrator:' di judul tab. Tapi bash WSL Ubuntu pada tab default saya menimpa apa pun yang mungkin ada di judul tabnya. Saya kira bash tidak tahu (atau bahkan peduli) tentang ketinggian Terminal Windows, sehingga info tidak dapat digunakan saat memperbarui judul dari dalam bash (tentu saja ada sudo situasi, tapi itu hal yang berbeda).

Di profiles.json Terminal, ada
"showTabsInTitlebar": false
tetapi dengan pengaturan ini, bilah judul Terminal tidak memberi sinyal ketinggian.

@janilahti melakukan tab CMD yang ditinggikan tidak terlihat seperti
untuk kamu?

Keamanan adalah poin yang diperdebatkan jika tidak ada yang ingin menggunakan alat Anda...

Anda harus membuat perintah Sudo untuk windows yang berfungsi di cmd.exe dan PowerShell. Itu akan menyelamatkan saya dari kesulitan memiliki pintasan untuk keduanya diatur untuk dijalankan sebagai admin.

FYI, saya menulis sudo for windows , disebut gsudo : https://github.com/gerardog/gsudo

Ini mendukung untuk meningkatkan perintah cmd / powershell / pwsh atau seluruh shell. Sangat mudah untuk menginstal dan menggunakan dan harus menyerupai *nix sudo asli. Ada implementasi sudo lain di alam liar tetapi IMHO, gsudo adalah yang paling serbaguna dan mudah digunakan.

Anda dapat menggunakannya, misalnya, untuk membuat profil WT yang memanggil gsudo cmd / gsudo pwsh atau gsudo WhateverShell untuk meluncurkan tab yang ditinggikan. Instal gsudo dan tambahkan profil WT:

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

Ini adalah aplikasi server-klien C# yang bertindak sebagai klien saat tidak ditinggikan, dan meluncurkan dirinya sendiri ditinggikan sebagai server. Kedua instance berkomunikasi melalui pipa bernama aman. Sudo jendela lain di alam liar sebagian besar seperti skrip 'runas' PowerShell yang memunculkan jendela baru, tetapi menjadi aplikasi lengkap memungkinkan saya menambahkan lebih banyak fitur.

Saya telah membaca utas dan keamanan perintah Sudo telah dibahas dan beberapa poin yang valid dibuat. Saya telah mengambil semua langkah keamanan yang dapat saya pikirkan dan saya terbuka (dan berencana) untuk memperkenalkan lebih banyak dari mereka. Pada titik ini seharusnya aman/tidak aman seperti jika Anda membuka sesi PS admin jarak jauh atau jika Anda melakukan ssh root@server dari konsol yang tidak ditinggikan. (mis. rentan terhadap penekanan tombol atau pengikisan layar, dan koreksi saya jika saya salah tetapi pemahaman saya adalah bahwa *nix Sudo juga rentan dengan cara ini). Ada juga cache kredensial, yang mengurangi jumlah popup UAC selama sesi 5 menit (terinspirasi dalam *nix Sudo), yang jelas merupakan vektor serangan, yang dapat dinonaktifkan melalui konfigurasi. Bagi mereka yang khawatir tentang keamanan, saya berencana untuk menambahkan cara yang sangat mudah untuk mengencangkannya (dengan menonaktifkan fitur seperti cache kredensial) dengan perintah sederhana atau melalui pengaturan kebijakan/registrasi grup perusahaan.

Satu hal menarik yang dibuat dalam komentar ini adalah bahwa Microsoft tidak mampu "menerima risiko demi kenyamanan pengguna". Jika itu adalah kata terakhir dari MS, maka setidaknya ini terlihat seperti solusi yang layak (berfungsi penuh), dan semua umpan balik/ masalah atau ide tentang cara meningkatkan keamanan disambut.

Tidak mungkin sesuatu yang harus saya instal yang tidak didukung secara resmi. Membunuh kemampuan apa pun untuk menggunakannya di lingkungan perusahaan.

Kemudian @hparadiz Anda harus menunggu hingga versi baru windows dirilis dengan desain keamanan baru yang memungkinkan sudo resmi (atau tab elevasi campuran) tanpa risiko keamanan. Sepertinya itu tidak akan terjadi dalam waktu dekat. Tembakan terbaik Anda adalah menunggu hingga seluruh WT dapat diluncurkan sebagai admin, dilacak di #4217, kemungkinan akan dirilis lebih cepat.

Menemukan peretasan yang bagus dari sebuah blog:

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

@gerardog apakah Anda memiliki ember sendok untuk gsudo ? atau di salah satu yang dikenal? Saat ini saya menggunakan kotak linux, jadi tidak dapat memeriksa.

@fluffynuts Ada di repo utama sendok. Jadi cukup 'sendok instal gsudo'. Juga metode instalasi lainnya tercantum di https://github.com/gerardog/gsudo . Tapi mari kita lanjutkan diskusi ini pada topik WT. 😉.

Pertanyaan terbuka: jika merupakan risiko keamanan untuk menggabungkan tab yang ditinggikan dan tidak ditinggikan, lalu apakah risiko itu ada di ConEmu ? Karena itu bisa melakukan hal itu. Atau apakah ConEmu mengimplementasikan fitur itu dengan cara yang berbeda dari yang Anda lakukan di Terminal? Dan secara lebih luas saya akan mencatat bahwa banyak fitur yang diminta di sini (di utas ini dan lainnya) sudah ada di terminal lain, ConEmu hanya satu contoh, jadi ketika pengembang Terminal menyarankan fitur ini tidak akan pernah diimplementasikan atau tidak diimplementasikan untuk untuk waktu yang sangat lama, Anda secara implisit hanya mengonfirmasi bahwa kami tidak boleh menggunakan Terminal.

jika kami tidak bergantung pada API yang hanya ada pada tahun 1903, kami tidak akan membutuhkan 1903.

@DHowett-MSFT Apakah ada dokumentasi publik yang tersedia mengenai API apa ini dan mengapa diperlukan? Karena sebagai pengamat luar, ketika saya melihat keputusan ini dan keputusan untuk menggunakan UWP, saya tidak melihat nilai tambah. Saya hanya melihat hambatan untuk menambahkan apa yang dianggap banyak pengguna perusahaan sebagai fungsionalitas dasar.

@dadpolice Lihat https://github.com/microsoft/terminal/issues/632#issuecomment -518888895 untuk mengetahui apa yang dilakukan ComEmu.

Saya pikir "UAC bukan penghalang keamanan" menurut Microsoft? Itu diperlakukan seperti satu di Vista. Kemudian kami diberitahu itu bukan satu dan masalah seperti ini adalah lelucon di Windows 7. Sekarang satu lagi hari ini?

Mungkin Anda perlu meninjau desain File Explorer dan daftar putih UAC dalam kasus ini. :)

Atau apakah itu hanya tergantung pada apakah itu alasan untuk mengambil jalan pintas dalam merancang sesuatu yang tidak boleh dilakukan oleh pengembang normal (File Explorer) atau tidak mengimplementasikan fitur penting (dalam hal ini)?

tidak menerapkan fitur penting (dalam hal ini)?

Saya ingin memperjelas - kami tidak mencoba _not_ mengimplementasikan fitur ini. Ini tentu saja merupakan fitur penting yang kami _ingin_ terapkan. Itu adalah sesuatu yang saya hadapi setiap hari sekarang - memiliki jendela tinggi kedua adalah _oke_ tetapi itu tidak _baik_.

Hanya perlu beberapa saat bagi kami untuk dapat merancang solusi aman yang tepat, kemudian juga melakukan upaya rekayasa untuk benar-benar mengimplementasikannya. Itu adalah sesuatu yang kami tulis untuk sementara minggu ini bahkan.

@zadjii-msft

[...]
Saya tidak berpikir kami berencana untuk mendukung tab campuran yang ditinggikan dan tidak ditinggikan, karena ini sedikit lubang keamanan.
[...]

(sebagai masalah menautkan utas terkait, #146)

Aneh bahwa orang-orang mendapat kesan bahwa fitur tersebut tidak akan diterapkan. tanda sarkasme

@kort3x Ada perbedaan antara "Tanpa Rencana" (alias kami tidak menjanjikannya) dan tidak ingin dan melakukan apa yang mereka bisa temukan cara untuk mengimplementasikannya.

Seperti yang dikatakan @zadjii-msft:

Hanya perlu beberapa saat bagi kami untuk dapat merancang solusi aman yang tepat, kemudian juga melakukan upaya rekayasa untuk benar-benar mengimplementasikannya. Itu adalah sesuatu yang kami tulis untuk sementara minggu ini bahkan.

Selama mereka tidak memiliki solusi aman, mereka tidak akan berencana (alias berjanji) untuk mendukung tab elevasi campuran. Saya bersedia menjadi bahwa yang kedua yang memiliki solusi aman mereka akan menambahkannya ke rencana (meskipun saya tidak bisa menjanjikan apa pun).

Saya pikir "UAC bukan penghalang keamanan" menurut Microsoft? Itu diperlakukan seperti satu di Vista. Kemudian kami diberitahu itu bukan satu dan masalah seperti ini adalah lelucon di Windows 7. Sekarang satu lagi hari ini?

Seperti yang saya pahami, ini adalah penghalang keamanan jika dikonfigurasi sebagai "Selalu beri tahu", jika tidak, tidak.

Nah, ini mengecewakan. Saya suka terminal (yang mengatakan banyak, karena saya cukup terpikat dengan alat non-MS secara umum), tetapi ketidakmampuan untuk meningkatkan dengan lancar adalah penghalang nyata bagi saya untuk melakukan lebih banyak pekerjaan pada OS ini.

LOL oke ya, saya bisa melihat bagaimana itu membingungkan. Saya awalnya menulis komentar itu beberapa hari setelah kami pertama kali mengumumkan, ketika tidak ada rencana. Setelah beberapa bulan berdiskusi, saya pasti sampai pada gagasan bahwa ini mungkin, dengan lebih banyak usaha. Saya akan memperbarui komentar untuk mencerminkan hal itu. @SamuelEnglard benar, sulit untuk _berkomitmen_ melakukan ini sampai kami _tahu_ bahwa itu mungkin dilakukan dengan benar.

Hal ini mendorong untuk mendengar. Apakah mungkin untuk memperluas antusiasme ini ke tim lain, jadi #3581 sebenarnya bisa diperbaiki?

Alangkah baiknya jika tab diizinkan untuk menjadi proses yang berbeda (mirip dengan cara chrome mengelolanya) sejak awal karena saya tidak perlu memulai ulang semua tab setelah mengelompokkannya dengan baik hanya untuk mendapatkan lingkungan yang diperbarui dalam satu cmd tab...
Setelah Terminal Windows hanya seorang manajer, itu bisa berjalan dalam mode non-elevasi sambil tetap memegang prompt perintah yang ditinggikan. Itu akan menyenangkan. (yah, menjalankan wt yang ditinggikan sambil memegang terminal yang tidak ditinggikan juga tidak masalah untuk saya)

@rapus95 secara teknis tabnya, dalam "konsol" adalah proses yang berbeda. Terminal Windows hanyalah seorang manajer

EDIT (14 Februari 2020)
Oke, jadi komentar ini tidak terlalu matang. Awalnya, ada _no_ rencana untuk mendukung ini, karena itu tidak akan bekerja dengan HWND tunggal yang kami miliki. Kami sedang berupaya merancang solusi yang _might_ mendukung ini di masa mendatang, tetapi kami tidak dapat berkomitmen pada apa pun sampai kami yakin bahwa kami dapat menemukan solusi aman yang tepat, yang memastikan bahwa proses dengan hak istimewa yang lebih rendah tidak dapat drive terminal hak istimewa yang lebih tinggi.

Selain beberapa poin lain, itulah alasan utama mengapa saya masih menggunakan ConEmu . Dan saya yakin saya akan pernah melakukannya.
https://conemu.github.io/ @Maximus5

Ini sangat bodoh.

Mari kita buat terminal terpadu baru untuk command prompt, powershell, dan bash untuk windows.
Bisakah saya menjalankan cmd.exe sebagai admin?
Tidak.

Hal bodoh seperti inilah mengapa mesin kerja utama saya masih Macbook.

@hparadiz Lihat ConEmu :-D Tidak ada masalah menjalankan banyak Shell sebagai tab dalam SATU Jendela; bahkan menjalankan sesi Powershell dan cmd.exe yang ditinggikan selain yang tidak ditinggikan.

@tmeckel apakah kami yakin conemu tidak memiliki kerentanan keamanan yang dikhawatirkan oleh tim terminal? pengguna sering memilih perangkat lunak yang kurang aman karena melakukan apa yang mereka inginkan, tetapi dengan risiko mereka sendiri.

@drdamour @tmeckel Memang benar. Saya mengajukan pertanyaan yang sama di atas, dijawab di utas lain: https://github.com/microsoft/terminal/issues/632#issuecomment -518888895

Saya sudah cukup kritis terhadap Terminal sejauh ini, tetapi untuk bersikap adil, ConEmu dan ConsoleZ dan alat serupa lainnya sudah ada. Ada sedikit nilai di Microsoft hanya dengan menyalinnya, tetapi ada nilai besar dalam menciptakan kembali fitur-fitur itu dengan cara yang aman. Yang mengatakan saya masih berpikir itu sangat konyol untuk membangun emulator terminal sebagai aplikasi UWP Store saja, terutama sekarang Microsoft tampaknya akan pindah dari UWP (misalnya Edge baru adalah aplikasi Win32).

Yang mengatakan saya masih berpikir itu sangat konyol untuk membangun emulator terminal sebagai aplikasi UWP Store saja, terutama sekarang Microsoft tampaknya akan pindah dari UWP (misalnya Edge baru adalah aplikasi Win32).

Untuk lebih jelasnya, Terminal tidak hanya untuk Toko ( ada .msix yang tersedia di sini ), juga bukan aplikasi UWP. Ini adalah aplikasi Win32 yang menggunakan UWP XAML sebagai kerangka UI-nya.

@rapus95 secara teknis tabnya, dalam "konsol" adalah proses yang berbeda. Terminal Windows hanyalah seorang manajer

Kalau begitu, mengapa lingkungan tidak diperbarui untuk instance cmd baru? Saya selalu perlu membuka Terminal Windows baru yang dalam beberapa hal mengurangi kegunaan keseluruhan memiliki banyak tab ...

@ rapus95 sementara saya tidak positif (saya harus menggali kode) saya cukup yakin setiap sub-proses diluncurkan dengan lingkungan induknya bukan yang baru.

itu sepertinya tidak masuk akal untuk manajer terminal

@rapus95 Sebenarnya ini adalah bug yang kami lacak di sini: #1125

Untuk lebih jelasnya, Terminal tidak hanya untuk Toko ( ada .msix yang tersedia di sini ), juga bukan aplikasi UWP. Ini adalah aplikasi Win32 yang menggunakan UWP XAML sebagai kerangka UI-nya.

Itu terdengar seperti UWP dengan langkah ekstra. Apa pun yang membuatnya jadi saya tidak bisa mengklik kanan pada Terminal dan menjalankannya sebagai pengguna yang berbeda, seperti yang saya bisa dengan aplikasi Win32 normal, itu adalah pilihan yang aneh.

Ini bukan aplikasi UWP atau aplikasi khusus Store.
Kebetulan salah satu metode distribusinya adalah Store, yang membutuhkan paket UWP.
Hanya mereka yang menginstalnya menggunakan toko yang tidak dapat Right click -> Run As Admin .
Copot pemasangan dan gunakan msix atau melalui sendok

Copot pemasangan dan gunakan msix atau melalui sendok

Atau chocolatey .

@gerardog Saya tidak mengatakan jalankan sebagai admin, saya katakan jalankan sebagai pengguna yang berbeda.

Tidakkah Shift + Right Click bekerja untuk Anda?

(Harap dicatat saya telah menginstal menggunakan scoop )

Tidak. Saya telah menginstal menggunakan paket msix dan opsi itu tidak ada.

Saya menginstal sebagai cokelat dan tidak menjalankan sebagai admin juga

Untuk lebih jelasnya, Terminal tidak hanya untuk Toko ( ada .msix yang tersedia di sini ), juga bukan aplikasi UWP. Ini adalah aplikasi Win32 yang menggunakan UWP XAML sebagai kerangka UI-nya.

Itu terdengar seperti UWP dengan langkah ekstra. Apa pun yang membuatnya jadi saya tidak bisa mengklik kanan pada Terminal dan menjalankannya sebagai pengguna yang berbeda, seperti yang saya bisa dengan aplikasi Win32 normal, itu adalah pilihan yang aneh.

Sama di sini, saya telah mencoba aplikasi msix dan store. Saya masih belum memiliki opsi "Jalankan sebagai pengguna berbeda".

Bagaimana dengan membuat semua latar belakang tab yang ditinggikan berwarna merah sehingga jelas bahwa itu ditinggikan?

Saya lebih suka ini dapat dikonfigurasi: warna latar belakang, judul tab ...

https://github.com/gerardog/gsudo berfungsi dengan baik sebagai solusi sementara

Mungkin menerapkan sesuatu seperti wt elevated yang membuka jendela baru yang ditinggikan dengan Shell saat ini dengan lingkungan yang sama.
EDIT: atau # 3158 tetapi sebagai jendela baru dan ditinggikan

Saya tidak mengerti mengapa Anda tidak menyalin cara Linux melakukannya.

Untuk pemahaman saya atau dunia Linux (koreksi saya jika saya salah), aplikasi terminal (gnome-terminal, mate-terminal ...) tidak perlu ditinggikan bahkan jika Anda mengetik su atau Sudo dan menjalankan perintah sebagai pengguna akar. Satu-satunya misi aplikasi terminal adalah menjalankan shell dalam proses yang berbeda (bash, ksh...) yang dinaikkan atau tidak, dan untuk mengarahkan ulang input dan output shell sehingga kita dapat berinteraksi dengan shell.

Jika Anda mengetik "su" atau memulai perintah dengan "sudo" di terminal linux, itu tidak akan membuka jendela lain.

@gabsoftware Saya tidak yakin tentang keamanan ini bahkan di Linux. Dimungkinkan untuk mengirim penekanan tombol ke X windows di Linux juga, dan tebakan saya adalah mungkin untuk mengirim penekanan tombol ke klien terminal yang berjalan di jendela X bahkan jika terminal yang berjalan ditingkatkan dengan sudo atau su. Bahkan dimungkinkan untuk mengirim penekanan tombol ke jendela X yang ditinggikan, tetapi saya benar-benar tidak tahu pasti.

Untuk lebih jelasnya, Terminal tidak hanya untuk Toko ( ada .msix yang tersedia di sini ), juga bukan aplikasi UWP. Ini adalah aplikasi Win32 yang menggunakan UWP XAML sebagai kerangka UI-nya.

Itu terdengar seperti UWP dengan langkah ekstra. Apa pun yang membuatnya jadi saya tidak bisa mengklik kanan pada Terminal dan menjalankannya sebagai pengguna yang berbeda, seperti yang saya bisa dengan aplikasi Win32 normal, itu adalah pilihan yang aneh.

Sama di sini, saya telah mencoba aplikasi msix dan store. Saya masih belum memiliki opsi "Jalankan sebagai pengguna berbeda".

Saya tidak dapat "Menjalankan sebagai pengguna yang berbeda" dengan menggeser-klik kanan ubin di menu mulai, tetapi saya dapat melakukannya jika saya menggeser-klik kanan WindowsTerminal.exe

@gabsoftware Saya tidak yakin tentang keamanan ini bahkan di Linux. Dimungkinkan untuk mengirim penekanan tombol ke X windows di Linux juga, dan tebakan saya adalah mungkin untuk mengirim penekanan tombol ke klien terminal yang berjalan di jendela X bahkan jika terminal yang berjalan ditingkatkan dengan sudo atau su. Bahkan dimungkinkan untuk mengirim penekanan tombol ke jendela X yang ditinggikan, tetapi saya benar-benar tidak tahu pasti.

Saya telah melakukan beberapa eksperimen, dan sekarang saya agak yakin dengan ketidakamanan ini di Linux. Saya bukan ahli keamanan, jadi saya tidak yakin tentang implikasinya (siapa pun?). Ternyata sangat mudah untuk mengirim penekanan tombol ke X windows yang baru saja menjalankan sudo dan terbuka untuk perintah sudo baru tanpa meminta kata sandi. Posting blog di sini , maaf untuk plug yang memalukan ...

Kesimpulan saya adalah bahwa kecuali ada cara untuk melarang pengiriman penekanan tombol ke jendela elevasi campuran, ini hanya boleh diterapkan sebagai opsi bagi pengguna yang mau menerima risiko (tanda peringatan besar, dll.).

Sebagai catatan tambahan, bagaimana keyboard di layar Windows mengirim penekanan tombol ke jendela yang ditinggikan?

Saya telah merilis gsudo v0.7 dan relevan dengan utas ini:

EDIT: Untuk konteks: gsudo adalah sudo untuk windows, dan memungkinkan untuk meningkatkan perintah sederhana atau shell di konsol saat ini. Saat dipanggil dari Cmd/Pwsh di dalam WT, itu meningkatkan tab. Juga, Anda dapat mengedit profil Anda, beri nama 'Elevated Powershell' dan ubah perintah Anda menjadi gsudo Powershell dan voilá, Anda mendapatkan profil tab yang ditinggikan. Lihat di sini .

Tetapi karena gsudo, atau sudo apa pun untuk windows, melompati isolasi UAC, itu telah diberi label 'tidak aman'. Berikut ini adalah solusi yang lebih rumit yang memungkinkan Anda melakukan elevasi tab yang beragam sambil menjaga keamanan. /AKHIR EDIT

gsudo sekarang dapat meluncurkan aplikasi dengan tingkat integritas apa pun. Misalnya kita dapat meluncurkan Windows Terminal dengan tingkat integritas MediumPlus , ini berarti mode 'semi-tinggi': tidak ada hak admin tetapi terisolasi, tidak dapat dijangkau dari proses reguler (Integritas Menengah) lainnya. (munculan UAC akan muncul)

Jadi, langkah pertama harus selalu meluncurkan WT dengan: gsudo -i MediumPlus WT
(Anda dapat mengubah pintasan WT Anda). Ini melindungi WT dari proses jahat, screen-scrapping, sendkeys, dll-injection, dll.
(EDIT: jika tidak berhasil gunakan: gsudo -n -i MediumPlus cmd /c cmd /c start wt )

Kemudian Anda dapat menggunakan gsudo dengan aman di dalam WT untuk meningkatkan perintah, atau bahkan membuat profil yang ditinggikan dengan: "commandline": "gsudo cmd.exe" di profiles.json

Kesimpulan saya adalah bahwa kecuali ada cara untuk melarang pengiriman penekanan tombol ke jendela elevasi campuran... ini hanya boleh diterapkan sebagai opsi bagi pengguna yang bersedia menerima risiko (tanda peringatan besar, dll.).

Selesai, dan selesai. (Saya telah menambahkan peringatan keamanan ke gsudo).

Juga, karena saya telah mengetahui bahwa jika pengguna menjalankan gsudo dari proses integritas reguler/Medium , maka cache kredensial gsudo (fitur untuk menampilkan lebih sedikit sembulan UAC) tidak akan pernah dapat sepenuhnya dilindungi... Jadi, sekarang kredensial cache harus diaktifkan secara eksplisit melalui gsudo cache on/off atau gsudo config cachemode auto .

Ternyata "Changing your WT shortcut" sama sekali tidak sepele: Mengingat model MSIX/AppStore, Anda mengalami #4217 dan #4459.

Skrip PowerShell berikut ini mengatasi masalah tersebut untuk membuat pintasan Terminal Windows di desktop dan mengaitkannya dengan tombol pintas 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()

Setelah Anda memulai WT sebagai MediumPlus (yaitu Ctrl+Alt+T), Anda dapat menggunakan gsudo seperti yang disebutkan [di atas] (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) untuk meningkatkan perintah dalam apa AFAIK harus aman.

Solusi saya untuk ini adalah menggunakan _Sudo for Windows_ Luke Samson . Konfigurasi profil adalah:
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
Saat memulai tab baru dengan profil itu, UAC muncul dan Anda berakhir di Powershell Core yang ditinggikan. Juga bekerja dengan terminal lain.
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
Jika Anda tidak menggunakan scoop , saya yakin konsepnya dapat diekstraksi dan digunakan secara mandiri. Lihat kode sumbernya di sini: https://github.com/lukesampson/psutils/blob/master/sudo.ps1

Saya menggunakan solusi schtasks untuk menjalankan Terminal Windows sebagai Administrator dan melewati UAC:

1. Mulai Penjadwal Tugas.
2. Buat tugas baru. Beri nama dan centang kotak "Jalankan dengan hak istimewa tertinggi".
   

3. Pada tab Tindakan, pilih untuk memulai program: wt

4. Pada tab Pengaturan, pastikan "Izinkan tugas dijalankan sesuai permintaan" dicentang dan hapus centang pada kotak "Hentikan tugas jika berjalan lebih lama dari".

5. Buat shortcut dengan mengklik kanan Desktop dan pilih New -> Shortcut dan ketik schtasks.exe /run /TN "{task name}"
   
6. Secara opsional, ubah ikon pintasan dan seret ke bilah tugas.

Sepertinya saya harus tetap menggunakan cmder sampai ini diperbaiki.

sekarang ada firasat tentang sebuah rencana, bisakah kita mendapatkan dokumennya
diperbarui untuk tidak lagi mengatakan tidak ada rencana saat ini?

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

@drdamour Setelah ada _is_ rencana, saya ingin menghapus bagian itu. Saat ini, hanya ada rencana untuk meneliti cara membuat rencana. Setelah ada rencana nyata, dan cara kita dapat melakukannya dengan aman, saya akan menghapus bagian itu.

Metode yang dijelaskan oleh @KMoraz berfungsi dengan baik sebagai solusi untuk saat ini. Terima kasih telah memposting ini.

Hai semua,

Saya menggunakan ConsoleZ sampai saya menemukan yang ini kemarin.
ConsoleZ memiliki beberapa fitur dan salah satunya adalah memulai tab baru sebagai administrator menggunakan UAC (itu akan memunculkan dialog UAC).
Saya merasa ini sangat berguna karena Anda tidak perlu menggunakan keyboard untuk membuka tab baru yang ditinggikan.

Bagaimana jika itu adalah konfigurasi di dalam konfigurasi profil? Begitulah cara melakukannya di ConsoleZ.

Halo semua,

Saya menemukan solusi Pintasan lain yang sederhana dan berfungsi baik bagi mereka yang harus memasukkan kredensial admin lokal saat menjalankan apa pun Sebagai Administrator.

Tautan ini menjelaskan, tetapi membutuhkan jalur lengkap untuk referensi wt.exe:
http://nuts4.net/post/windows-terminal-run-as-admin

String pintasan lengkap saya adalah: C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

PEMBARUAN 21 Mei 2020:
Di atas dulu berfungsi sebelum versi 1.0.1401.0.

Lihat masalah baru ini juga: https://github.com/microsoft/terminal/issues/6013

Sekarang klik Crtl-Shift TIDAK berfungsi baik ketika Anda harus meningkatkan dengan akun admin lokal.

Lihat tangkapan layar kesalahan di bawah ini yang saya dapatkan setelah diminta dua kali untuk meningkatkan izin:

Sebagai informasi, imho gsudo sangat cocok untuk ini, thx https://github.com/microsoft/terminal/issues/632#issuecomment -613751789

Konfigurasi saya hanya memiliki profil ini untuk mendapatkan hak istimewa:

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

Bagi saya cara termudah untuk membuka Terminal Windows sebagai administrator, adalah dengan menyematkannya sebagai item pertama di bilah tugas. Kemudian Win+Ctrl+Shift+1 membukanya sebagai admin

Bagi saya cara termudah untuk membuka Terminal Windows sebagai administrator, adalah dengan menyematkannya sebagai item pertama di bilah tugas. Kemudian Win+Ctrl+Shift+1 membukanya sebagai admin

Memang sangat nyaman, tetapi ini hanya berfungsi untuk akun yang menjadi anggota grup Administrator.

Jika Anda bertindak sebagai admin untuk orang lain, Anda tidak akan dapat menjalankan Terminal Windows sebagai pengguna (admin) Anda dari akun mereka.

Saya pikir akan lebih baik untuk memiliki satu pengaturan tab untuk menjalankan cmd sebagai administrator bukan segalanya.

Saya pikir akan lebih baik untuk memiliki satu pengaturan tab untuk menjalankan cmd sebagai administrator bukan segalanya.

Seperti yang dijelaskan di tempat lain di sini, ini tidak mungkin dengan desain saat ini.

apakah ada flag yang bisa digunakan untuk menjalankan sebagai admin? Kemudian kita bisa membuat jalan pintas untuk itu.

Jika Anda menyematkan Terminal Windows ke bilah tugas, Anda dapat meluncurkannya _ditinggikan_ menggunakan Ctrl+Shift+klik.

Ini akan melakukan hal yang sama seperti klik kanan pada ikon, klik kanan pada "Terminal Windows", diikuti oleh "Jalankan sebagai administrator."

Catatan: Terminal Windows menjadi aplikasi Store, Anda tidak dapat menjalankannya sebagai _pengguna lain_.

Saya ingin melihat kemampuan untuk memiliki "tab tingkat integritas campuran" di Terminal Windows, dengan tingkat integritas sebagai opsi di setiap profil. Ini sebagian besar sebagai kenyamanan dalam pekerjaan sysadmin/devops normal saya untuk meminimalkan gangguan alur kerja dan peralihan konteks.

Saya telah menemukan alternatif sederhana yang cocok untuk saya saat ini. Ini tidak membahas semua skenario yang disajikan di sini oleh pengguna lain. Itu tidak bergantung pada aplikasi pihak ketiga, file pintasan, kombinasi tombol, atau Tugas Terjadwal. Itu tidak memerlukan mengidentifikasi lokasi Terminal Windows yang dapat dieksekusi. Itu hanya membuat entri terpisah dalam daftar profil Terminal Windows yang meluncurkan instance Terminal Windows kedua yang ditinggikan. Ini memicu prompt UAC sekali. Saya hanya menggunakan ini jika dan ketika saya membutuhkan ketinggian.

Hasilnya adalah dua Terminal Windows. Apa pun di satu adalah standar dan apa pun di yang lain ditinggikan. Bagi saya, ini merupakan tingkat interupsi dan peralihan konteks yang dapat diterima. Terminal Windows yang ditinggikan juga menambahkan setiap judul tab dengan "Administrator:" yang memberikan konfirmasi visual yang baik tentang perbedaannya.

Sunting: Saya telah menginstal Powershell 7,

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

@IarwainBen-adar, sepertinya saya ingat baru-baru ini membaca di dokumen baru bahwa Anda tidak dapat menggunakan item commandline dan item source bersama-sama. Apakah ini berfungsi seperti yang diharapkan tanpa item source ?

Saya mencoba kodenya dan bahkan tidak bisa membuat item baru muncul di tarik
menu bawah.

@shem-sargent maaf tentang itu, saya menghapus komentar saya di sini karena deklarasi source yang asing memang masalahnya. Meskipun, sekarang saya memiliki entri menu yang berfungsi, sayangnya saya masih tidak dapat meluncurkan instance Terminal Windows yang ditinggikan - saya mengalami masalah #3145 dengan kegagalan The file cannot be accessed by the system.

@IarwainBen-adar Maaf, saya tidak dapat mereproduksi #3145. Kalau tidak, saya akan mencoba pemecahan masalah di pihak saya.

sematkan ke bilah tugas dan geser + klik kanan

Cheers @LordFPL dan tentu saja @gerardog , saya belum pernah mendengar tentang gsudo (https://github.com/gerardog/gsudo untuk orang lain yang tertarik) sebelumnya, tetapi ini membuat sesi yang ditinggikan menjadi mudah sekarang. Terima kasih! Tambahkan ke objek profil di file pengaturan, atau cukup gunakan alias sudo seperti yang Anda lakukan di sistem Linux. Sempurna!

@zadjii-msft saya minta maaf, tapi saya tidak begitu mengerti apa masalahnya di sini. Windows mendukung manipulasi token dan peniruan identitas, itu cara kerja runas bukan? menggunakan gsudo dari @gerardog saya dapat memiliki integritas rendah (er) dengan hosting shell integritas tinggi (er) pada saat yang sama dengan shell integritas tingkat lainnya, baik itu PowerShell, pwsh, cmd, atau shell wsl apa pun. Dari pengujian terbatas saya, tidak ada shell integritas rendah (er) yang dapat men-debug ke shell integritas yang lebih tinggi itu. Apa hambatan di sini untuk memiliki ini sebagai terminal bawaan, atau bahkan lebih disukai di tingkat OS, fitur?

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

Jendela berintegritas rendah _menerima masukan dan menyalurkannya langsung ke proses berintegritas tinggi_ membuka proses berintegritas tinggi itu ke atas untuk dikendalikan oleh hal-hal berintegritas rendah lainnya pada sistem.

Ini berarti proses yang berpotensi berbahaya hanya membutuhkan gerakan lateral pada tingkat hak istimewa yang sama untuk mendapatkan EoP.

@smokeintheshell #632 (komentar)

Jendela berintegritas rendah _menerima masukan dan menyalurkannya langsung ke proses berintegritas tinggi_ membuka proses berintegritas tinggi itu ke atas untuk dikendalikan oleh hal-hal berintegritas rendah lainnya pada sistem.

Ini berarti proses yang berpotensi berbahaya hanya membutuhkan gerakan lateral pada tingkat hak istimewa yang sama untuk mendapatkan EoP.

ya, saya membaca penjelasan itu di awal utas, tetapi saya tidak mengerti mengapa itu baik untuk Linux, dan mungkin Mac, tetapi tidak untuk Windows? Windows saat ini melindungi input ke proses yang ditinggikan dari proses yang tidak ditinggikan. Baik dalam masalah ini atau yang terkait, seseorang menyarankan agar kami memerlukan proses terpisah per tab. Saya pikir ini sudah terjadi karena setiap tab memiliki perintahnya sendiri untuk dieksekusi (misalnya: pwsh.exe). Apakah karena mereka semua adalah anak-anak dari proses root yang sama di bawah satu HWND?

Apakah terminal Ubuntu mengalami masalah yang sama dengan tab jika saya:

• memiliki tab dengan su terbuka
• memiliki tab di mana saya telah meningkat dengan sudo dan tidak perlu memasukkan PW saya lagi per kebijakan konfigurasi?

Atau apakah arsitektur Ubuntu entah bagaimana mengeras terhadap serangan injeksi input lintas proses?

Apakah terminal Ubuntu mengalami masalah yang sama dengan tab jika saya:

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

Atau apakah arsitektur Ubuntu entah bagaimana mengeras terhadap serangan injeksi input lintas proses?

Jika Anda melihat komentar saya di sini , saya sebenarnya telah mereproduksi / mengeksploitasi masalah di Linux. Baik su dan sudo mungkin sama-sama "rentan", karena Anda dapat mengirim penekanan tombol ke jendela berintegritas rendah yang menjalankan perintah tersebut. Batas waktu kata sandi sudo (tidak harus memasukkan kata sandi Anda pada perintah sudo berikutnya dalam waktu 15 menit), membuatnya lebih mudah. Anda dapat mengeraskan Ubuntu dengan menonaktifkan ekstensi X yang diperlukan untuk serangan itu. Tidak yakin apakah ini mungkin di lingkungan Wayland (serangan dan/atau pengerasan).

Saya sepenuhnya memahami keputusan untuk tidak menerapkan tab elevasi campuran, kecuali ada beberapa cara untuk menonaktifkan keyboard virtual dan metode input perangkat lunak lainnya.

Saya pikir ini sudah terjadi karena setiap tab memiliki perintahnya sendiri untuk dieksekusi (misalnya: pwsh.exe). Apakah karena mereka semua adalah anak-anak dari proses root yang sama di bawah satu HWND?

@kbirger Ya ada proses terpisah untuk setiap tab, tetapi semua input mouse dan keyboard Anda masih dikirim ke jendela Terminal Windows (yang berintegritas rendah), kemudian dirutekan ke setiap proses shell melalui aliran input standar. Begitulah cara semua pintasan keyboard Terminal Windows bekerja.

Saya ingin tahu apakah mungkin mendeteksi jika input dipalsukan, misalnya menggunakan API GetCurrentInputMessageSource . Saya tidak dapat menemukan banyak informasi tentang API ini selain dari contoh resmi, tetapi dari deskripsi itu harus dapat mengidentifikasi sumber input (perangkat keras/dari proses dengan uiAccess, sebagian besar perangkat lunak aksesibilitas/dari proses tanpa uiAccess, mungkin berbahaya)

mengapa tidak apa-apa untuk Linux, dan mungkin Mac, tetapi tidak OK untuk Windows?

Saya cukup yakin bahwa salah satu dari tiga alasan adalah bahwa Microsoft menjual keamanan sebagai fitur kepada perusahaan besar lainnya, atau pemerintah.

Ada juga beberapa resonansi lain yang muncul di benak saya mengapa itu mungkin tidak menjadi masalah sampai sekarang:

• Untuk waktu yang lama, dan berbagai alasan (seperti "peretas" tidak menyukai Windows, dan "semua orang" menggunakan Windows ^^), Windows dulunya adalah target (≈hanya) utama dari semua jenis malware. Itu membutuhkan keamanan yang lebih baik (melindungi jendela yang ditinggikan), sementara yang lain tidak terlalu peduli.
• Seperti yang dijelaskan sebelumnya dalam masalah ini, seharusnya malware tidak dapat dengan mudah mengakses host konsol Anda yang ditinggikan di Windows, jadi kemungkinan tidak banyak yang berinvestasi dalam masalah itu (saya bukan ahli keamanan, jadi saya tidak tahu jika ada yang punya)
• Malware biasanya memiliki cara lain untuk meningkatkan dirinya sendiri daripada mencoba menemukan command prompt yang ditinggikan di OS pilihan Anda
• Hanya pengembang dan sysadmin yang menggunakan terminal (ini hanya mengurangi demografi target serangan; pemerintah dan perusahaan besar masih menjadi perhatian)

Sekarang, dengan memperkenalkan fitur secara naif (seperti yang telah kita semua lakukan, saya yakin ) Anda akan memperkenalkan kelemahan (besar) baru di beberapa instalasi Windows. Dengan pengembangan yang dilakukan di tempat terbuka, Anda dapat yakin bahwa semua orang yang membutuhkan akan menyadari kekurangannya dan mulai membuat kode untuk melawannya.
Penanggulangan cepat adalah dengan melarang Terminal Windows (dan kemungkinan semua emulator terminal lain di luar sana sekarang karena kelemahannya bersifat publik), Anda kemudian dapat mengucapkan selamat tinggal pada impian Anda untuk menggunakan Terminal Windows di lingkungan perusahaan apa pun

Saya masih sangat berharap bahwa versi aman dari fitur ini akan terlihat jelas, meskipun

Saya melihat. Terima kasih atas penjelasannya!

Sebagai catatan tambahan, bagaimana keyboard di layar Windows mengirim penekanan tombol ke jendela yang ditinggikan?

@mrwensveen AFAIK ada tiga cara untuk mengirim input ke jendela yang ditinggikan:

1. Tinggikan dirimu. Namun Anda tetap tidak dapat mengirim input ke proses sistem (mis. Pengelola Tugas, dialog UAC, layar login).
2. Daftarkan Layanan Windows. Sekarang program Anda berjalan sebagai SISTEM sehingga Anda dapat melakukan apapun yang Anda inginkan. Saya telah melihat beberapa program Akses Jarak Jauh melakukan ini.
3. Deklarasikan flag uiAccess , tandatangani biner Anda secara digital, instal ke lokasi yang tidak dapat ditulisi untuk pengguna saat ini. Ini adalah "pintu belakang" untuk perangkat lunak aksesibilitas, memungkinkan mereka untuk membaca/menulis program lain (termasuk proses sistem), dan ditampilkan di atas jendela lain (termasuk Desktop Aman tempat munculan UAC ditampilkan dan layar masuk), semuanya tanpa berjalan lebih tinggi. Lihat https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

Keyboard di Layar (osk.exe), Narrator.exe (, dan mungkin pembaca layar lainnya) semuanya menggunakan metode 3.

(Tangkapan layar yang menunjukkan manifes program tertanam osk.exe dengan uiAccess=true )

Sepertinya flag uiAccess juga bisa melindungi program agar tidak diakses oleh program lain yang berintegritas rendah (walaupun masih berjalan tanpa elevasi), mungkin kita bisa menggunakan "fitur" ini untuk melindungi WT?

@yume-chan Keren, itu sangat menarik, terima kasih! Apakah program uiAccess diperbolehkan mengirim penekanan tombol ke program uiAccess lainnya? Kami masih ingin OSK dapat berinteraksi dengan terminal windows, dan jika ini berarti program lain setidaknya harus ditandatangani sebelum diizinkan untuk mengirim input ke terminal windows, apakah itu penghalang yang cukup tinggi?

Apakah program uiAccess diizinkan untuk mengirim penekanan tombol ke program uiAccess lainnya?

@mrwensveen Ya, program dengan hak istimewa uiAccess dapat saling mengakses.

Saya lebih suka cara API GetCurrentInputMessageSource (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562) karena ini bukan penggunaan yang dimaksudkan uiAccess . Juga dengan API, kami mungkin masih mengizinkan program dengan integritas rendah untuk mengirim penekanan tombol ke tab yang tidak ditinggikan, sementara tidak ke tab yang ditinggikan.

Solusi kecil yang saya buat di sini:

Saya telah menginstal PowerToys yang memiliki beberapa fitur keren. Salah satunya adalah untuk menunjukkan cara pintas windows dan saya telah menemukan bahwa ketika Anda menekan Win + nomor, membuka aplikasi di jendela bar sesuai dengan nomor yang muncul di bar.

Jadi, saya telah meletakkan terminal di bilah sebagai ikon pertama
.

Ketika saya menekan Win + 1, terminal terbuka.

Ketika saya menekan Win + Ctrl + Shift + 1, itu terbuka tinggi.

Saya akan meletakkan konfigurasi terminal dan profil PowerShell saya di sini juga jika Anda ingin mendapatkan fitur show the git branch dan conda environment di Prompt dan pengguna berwarna merah jika itu adalah terminal yang ditinggikan ...

Itu sudah ada setidaknya sejak Windows 7; itu bukan hal PowerToys.

@Firehawke Ya, saya baru tahu karena PowerToys ... tidak perlu begitu.

Berikut adalah profil untuk meluncurkan yang ditinggikan yang berfungsi di Windows Store & memiliki ikon yang tepat:

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

EDIT: Kredit ke @glooms , @shem-sargent, @LordFPL , dan @Firehawke untuk komponen berbeda dari cuplikan ini. Saat perintah ini memanggil pwsh.exe , sepertinya beberapa orang mengalami #4228 (kesalahan 0x80070002 saat meluncurkan) dengan ini karena variabel lingkungan PATH yang rusak atau binari aneh di jalur mereka bernama powershell.exe atau pwsh.exe . @zurkz memperbaikinya dengan merujuk powershell.exe , tapi saya rasa itu tidak dapat diandalkan sekarang. #6684 mengatasi masalah ini untuk Terminal Windows, dan Anda akan menemukan versi tetap di bawah ini, mengikuti solusi itu, yang seharusnya tidak memiliki masalah ini sama sekali.

Berikut adalah profil untuk meluncurkan yang ditinggikan yang berfungsi di Windows Store & memiliki ikon yang tepat:

{
    "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 Itu bekerja dengan baik! Terima kasih.

Berikut adalah profil untuk meluncurkan yang ditinggikan yang berfungsi di Windows Store & memiliki ikon yang tepat:

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

Berikut adalah profil untuk meluncurkan yang ditinggikan yang berfungsi di Windows Store & memiliki ikon yang tepat:

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

@siapapun Maafkan ketidaktahuan saya, apakah ini dijatuhkan di konfigurasi Windows Store? Jika demikian, dapatkah seseorang memposting jalurnya? Jika tidak, di mana anak nakal ini seharusnya tinggal?

TYIA!

@Kazamario
Itu masuk ke file Windows Terminal settings.json, di bagian profil.

Ini menyebabkan kesalahan: 0x80070002 saat meluncurkan. pwsh 7.1.

Saya mengubahnya menjadi:

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

dan UAC diminta untuk meningkatkan izin.

Saya mengubahnya menjadi:

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

dan UAC diminta untuk meningkatkan izin.

yang bekerja untuk saya cukup baik. Terima kasih!

Berikut adalah cara memulai Terminal Windows yang ditinggikan jika disematkan ke Mulai.
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

@narfanar Sepertinya Anda mengalami #4228, di mana Terminal Windows mengeluarkan kesalahan 0x80070002 saat startup ketika variabel lingkungan PATH kacau atau binari lain mengambang di jalur bernama powershell.exe atau pwsh.exe . Saya tidak berpikir cuplikan @zurkz benar-benar memperbaiki ini, karena hanya menggeser potensi masalah dari pwsh.exe ke powershell.exe . #6684 memperbaiki ini untuk WT, jadi inilah cuplikan yang disesuaikan dengan solusi itu:

{
    "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 melakukan ini dengan baik

Perhatikan bahwa Cmder memiliki fitur ini, yang sangat berguna. Akan senang melihatnya diimplementasikan di Terminal Windows. Bahkan jika harus meluncurkan jendela terpisah untuk tab Admin atau sesuatu..

profil default saya diatur ke bash daripada powershell, dan saya ingin tetap seperti itu. cuplikan di atas berfungsi dengan baik, tetapi saya senang dapat membuatnya meluncurkan terminal baru yang ditinggikan dengan profil PowerShell dimuat. Saya menghabiskan waktu 3 jam untuk mencoba mencari tahu (bukan penggemar berat / memiliki banyak pengalaman dengan PowerShell) dan saya tidak dapat menemukannya -- mohon bantuannya. sepertinya ada beberapa kombinasi dari tanda kutip tunggal, tanda kutip ganda, melarikan diri, spasi, baris baru, yang mungkin membuatnya bekerja tetapi saya tidak bisa memulai proses dan daftar argumen untuk melakukan apa yang saya inginkan. saya rebus menjadi:

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
ini berfungsi dalam file .ps1 jika saya menjalankannya sendiri, saya mendapatkan terminal windows baru yang ditinggikan dengan profil PowerShell dimuat. tetapi tidak berfungsi di parameter baris perintah dari settings.json, tidak peduli bagaimana saya mencoba untuk memotongnya, secara eksplisit memanggil daftar argumen alih-alih menggunakan cmd /c, berbagai bentuk penggunaan melarikan diri dan kutipan, dll.

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
tidak bekerja. yang terbaik yang bisa saya lakukan adalah membuatnya meluncurkan hibrida aneh dari apa yang saya inginkan. tidak mendapatkan jendela "Administrator: Ubuntu", yang terlihat seperti profil bash saya tetapi sebenarnya menjalankan PowerShell. font yang salah dan semuanya. jika saya menggunakan jendela itu untuk membuka tab PowerShell baru, itu akan dinaikkan sesuai keinginan. ketika seperti ini saya dapat memasukkan sampah apa pun yang saya inginkan ke bagian "Windows PowerShell" dari pemuatan profil dan saya mendapatkan perilaku yang sama persis, jadi saya tahu itu tidak benar-benar mencoba memuat profil yang saya lewati.

Jadi saya mengalami masalah saat mencoba menjalankan ini sebagai yang ditinggikan, saya telah melakukan setiap opsi yang tercantum di atas dan saya mendapatkan kesalahan "Tidak dapat menemukan file" atau ini.

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

Adakah orang lain yang masih mengalami masalah atau belum bisa menjalankannya dengan baik?

profil default saya diatur ke bash daripada powershell, dan saya ingin tetap seperti itu.

Gerakan mengungkap kekerasan seksual demi menghapuskannya. Saya menjalankan WSL hampir sepanjang waktu, tetapi kadang-kadang saya perlu menjalankan PS yang ditinggikan, dan saya ingin melakukannya di tab WT baru.

Saya juga tidak dapat membuat salah satu contoh berfungsi - bahkan dengan mengoreksi jalur file saya. Saya menemukan dan menginstal gsudo yang dapat meningkatkan tab saat ini, atau digunakan sebagai profil untuk membuka tab yang ditinggikan di jendela yang sama. Saya tidak yakin apakah solusi di atas dimulai di jendela baru (beberapa upaya yang saya lakukan sebelum menggunakan gsudo hanya akan dimulai di jendela baru). Ini akan membuka popup UAC.

Ini adalah profil yang saya gunakan:

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

Saya menggunakan supressApplicationTitle sehingga judul tab tidak menampilkan Administrator: sebagai berlebihan dengan Elevated .

@ayfine Jika https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 memang tidak berfungsi untuk Anda, dapatkah Anda mengirim transkripsi kesalahan persis/perilaku tak terduga yang Anda dapatkan dengan konfigurasi itu? (Pastikan untuk menambahkan konfigurasi tambahan, seperti suppressApplicationTitle , dalam langkah sekecil mungkin, sehingga jika konfigurasi Anda melanggar WT, akan lebih mudah untuk mengetahui di mana & kapan itu terjadi.)

Jika ada konfigurasi lain di sini yang sedikit lebih jauh dari yang ditautkan untuk Anda, detail tentang cara pemecahannya juga akan dihargai.

@ bb010g Saya tidak menemukan pesan kesalahan apa pun - saya minta maaf karena tidak lebih tepat dalam balasan saya. Saat menggunakan https://github.com/microsoft/terminal/issues/632#issuecomment -663686412 saya mengalami masalah Terminal Windows memuat shell WSL Ubuntu saya (default saya). Saya telah menganggap ini awalnya berarti bahwa itu tidak berfungsi dengan benar tetapi saya melihat sekarang bahwa di jendela baru itu, jika saya memulai tab Powershell (profil default) baru, itu sebenarnya ditinggikan. Terlepas dari itu, baik dengan membuka jendela baru dan harus memulai tab baru di dalamnya, itu tidak lebih mudah daripada menjalankan proses yang ditinggikan dari menu mulai saya. Apa yang saya jelaskan dalam balasan asli saya memberikan perilaku persis seperti yang saya bayangkan.

@ayfine - dan saya menyalin contoh gsudo Anda. Itu solusi yang cukup baik sampai sesuatu yang ada di dalamnya dikodekan. Terima kasih.

@ayfine Saya mencoba hal gsudo, tapi ini pengalaman yang sangat buruk. Segala jenis penyelesaian TAB tampaknya rusak, dan karakter Unicode (non-ASCII) tampaknya tidak ditampilkan. Saya menduga ini semacam proses yang mengarahkan ulang input dan output, dan melakukan pekerjaan yang buruk. Saya pikir solusi dengan jendela terpisah bekerja lebih baik.

Jika Anda mengalami masalah dengan gsudo, harap laporkan ke @gerardog dan bukan di utas ini. Setiap pesan di utas ini (termasuk yang ini; maaf!) ​​mengirim email ke ratusan pelanggan.

Saya akan mengunci utas ini untuk komentar non-pengelola lebih lanjut, karena kami mencapai titik di mana komentar lebih lanjut tidak memajukan diskusi dalam jumlah yang berarti.

Silakan ajukan masalah baru jika Anda memiliki masalah yang tidak tercakup di sini.