VIM: "sudo vim bad_idea"?


20

Pengguna irc di #Vim mendesak saya untuk tidak menggunakan Sudo dengan Vim seperti:

sudo vim bad_idea

Ketika saya melakukan hal-hal di lokasi seperti / var / www /, saya tidak bisa menulis tanpanya. Jadi tidak menggunakan sudo menjadi masalah. Tentu saja, saya bisa membuat perubahan di lokasi yang berbeda seperti / tmp / dan kemudian salin direktori ke / var / www. Namun, saya merasakan cara yang lebih mudah.

  1. Jika Anda tidak "sudo Vim", mengapa?
  2. Jika ya untuk pertanyaan pertama, bagaimana Anda menghindari masalah untuk tidak menggunakan sudo?

Jawaban:


35

Saya termasuk dalam kategori pertama: sudo vim /var/www/html/some_fileadalah ide yang buruk; itu memungkinkan shell lolos yang tidak dicatat. Sebaliknya, gunakan sudoedit /var/www/html/some_file; yang memiliki efek yang sama.


5
Apakah "shell escapes yang tidak masuk"? dan mengapa tidak hanya penting di / var / www?
hasen

6
vim memiliki kekuatan untuk menjalankan perintah lain pada baris perintah. Namun, karena vim dimulai melalui sudo, dan karena itu berjalan sebagai root, salah satu dari perintah itu akan berjalan dengan hak akses root. Perintah-perintah ini dikenal sebagai "shell escapes" dan tidak mencatat cara pemanggilan sudo lainnya. Dan itu tidak terbatas hanya pada / var / www; di mana-mana saya akan menggunakannya. Saya bahkan telah alias "sudo vi" ke "sudoedit" di file bashrc saya.
Kevin M

Saya melihat apa yang Anda maksudkan dan ingin menyetujui tetapi mengklarifikasi. Kami tidak tahu apakah aktivitas normal su dan sudo-nya sedang dicatat atau tidak. "sudo vim" memungkinkan menjalankan subkulit sebagai root - yang akurat; di dalam shell itu, "sudo" tidak akan mengendalikan apa yang root bisa dan tidak bisa lakukan.
pbr

3
Kevin, bagaimana Anda mengatur alias "sudo vi" menjadi "sudoedit"? Dari manual bash ... "Karakter /, $,`, dan = dan semua karakter meta shell atau mengutip karakter yang tercantum di atas mungkin tidak muncul dalam nama alias. " ... ruang adalah salah satu dari metakarakter yang dibicarakannya.
pbr

9
OK, jadi ini bukan alias, tetapi memiliki efek yang sama: 'function sudo () {[[$ 1 == vi]] && shift && sudoedit "$ @" || perintah sudo "$ @"; } '
Kevin M

10

Refer: /programming/1005/getting-root-permissions-on-a-file-inside-of-vi :

% diganti dengan nama file saat ini, sehingga Anda dapat menggunakan:

: w! sudo tee%


Jika Anda akan menggunakan tee, saya sarankan ': w! Sudo tee%> / dev / null' sehingga Anda tidak melihat seluruh file bergema kembali kepada Anda. Saya biasanya menggunakan ': w! Dd =%' sebagai gantinya karena lebih cepat untuk mengetik dan mencapai hal yang sama. Tentu saja, ini hanya ketika saya lupa menggunakan sudoedit / sudo -e.
jamessan

7

vim memungkinkan pengguna untuk menjalankan perintah shell sewenang-wenang, oleh karena itu banyak admin sistem tidak mengizinkan vim untuk digunakan dengan sudo.

rvim disertakan dengan vim. Ini adalah vim terbatas, yang tidak memungkinkan perintah shell. (Atau memungkinkan Anda untuk menangguhkan vim, untuk alasan yang sama.)

Apakah Anda perlu pergi ke ekstrem di kotak Anda sendiri masih bisa diperdebatkan.


1
+1. Sangat setuju. sudo vimlalu masuk :!bashdan Anda memiliki shell sebagai root - persis mengapa rvimada
dbr

3
Sebenarnya jika Anda bisa sudo vim, Anda mungkin bisa sudo bashatau tidak sudo su -?
dlamblin

@diamblin Privileges dapat dikumpulkan dengan detail yang lebih baik dari itu, jadi belum tentu. Itu sebabnya diperlukan rvim. "sudo vim" sama dengan "sudo su -" untuk semua maksud dan tujuan. Pada kotak bitty-Debian di mana satu pengguna adalah administrator sistem, ini semua bersifat akademis.
Richard Hoskins

Bagaimana cara ubuntu menangani masalah ini? Pada CentOS vidiluncurkan vimtetapi sebagai root vidiluncurkan vi. Di Ubuntu vimdigunakan dalam kedua kasus dan sudo vijuga meluncurkan vim...
cwd

6

Saat mengedit file konfigurasi sistem, itu benar-benar oke --- selalu ingat Anda root dan dengan demikian memiliki semua kekuatan, dan jatuhkan hak istimewa itu segera setelah Anda tidak membutuhkannya lagi.

Dalam kasus khusus /var/www/, yaitu halaman server web, Anda mungkin ingin berpikir tentang mengubah beberapa kepemilikan / grup / izin --- tetapi jika dan seberapa besar tergantung pada pengaturan khusus Anda (pengguna tunggal / multi, server web nyata / hanya localhost, dinamis / statis, dll.)


6
+1 memang - ini adalah cara terbaik untuk menangani halaman server web. Pastikan Anda memiliki akses ke sana daripada meningkatkan hak istimewa Anda.
bedwyr

1
-1 tidak ada alasan untuk menjalankan vim dengan hak istimewa yang ditingkatkan ketika sudoedit akan melakukan pekerjaan yang sama.
sml

4

Pertanyaan seperti ini membuatku menampar dahiku. Saya berada di sisi lain dari keamanan, "keamanan seharusnya tidak mengganggu pengalaman pengguna, kecuali jika itu diharapkan atau diperlukan untuk mencegah orang biasa melakukan aktivitas jahat."

Mencegah penggunaan sudo vim hanyalah bantuan band. Seperti yang dinyatakan sebelumnya, seseorang dapat menggunakan:

sudo su -

Atau

sudo /bin/bash

Atau

sudo nano file

Atau

sudo my_exectuable_text_editor file

dll

Jika Anda benar-benar khawatir tentang seseorang yang melakukan sesuatu yang berbahaya pada kotak itu, jangan beri mereka hak istimewa sudo (atau root password), titik. Tidak ada sliver bullet untuk mencegah aktivitas jahat menggunakan sudo dan Anda hanya akan membuat diri Anda gila dengan "menerapkan" semua "perbaikan" untuk memastikan seseorang tidak dapat melakukan sesuatu yang berbahaya.

Seseorang menyebutkan perubahan kepemilikan / grup. Ini adalah masalah lengket seolah-olah server web dijalankan sebagai pengguna lain, dan Anda mengubah izin pada file tersebut, sekarang tiba-tiba situs Anda tidak berfungsi. Yah, jelas itu tidak akan membantu Anda. Anda dapat menambahkan diri Anda ke grup yang dijalankan server web, namun, jika grup tidak memiliki akses tulis ke file, Anda perlu melakukan chmod -R g + w * (atau file chmod individual) yang mungkin tidak apa yang Anda inginkan dan dapat merepotkan jika Anda harus chmod setiap file.

Beberapa orang bahkan menyarankan menggunakan rvim. Tentu, seseorang hanya dapat menambahkan baris di / etc / sudoers untuk hanya mengizinkan pengguna tertentu untuk sudo rvim, namun, secara logis akan bertahan bahwa jika Anda harus pergi rute itu, mungkin lebih baik untuk mengimplementasikan file manager berbasis web. Dengan cara ini berjalan sebagai pengguna server web berjalan, sehingga tidak ada masalah izin file dan Anda masih dapat memiliki kontrol granular atas siapa yang mengedit file apa.

Lagi pula, dua sen saya.


2

Menjalankan sudo vimtidak akan mengubah $HOMEdirektori, jadi Anda akan menjalankan Vim dengan izin root, tetapi $HOMEmasih menunjuk ke pengguna normal Anda.

Jika ini adalah pertama kalinya Anda menjalankan Vim, mungkin saja ~/.viminfofile tersebut dibuat di dalam direktori pengguna normal Anda, tetapi dengan izin root.


1
Tergantung pada sudo. Di laptop saya sudo vim -c '!echo $HOME' -c qmemang memberikan folder rumah saya, tetapi di server saya itu memberikan /root. Saya mungkin harus melihat mengapa itu, bisa karena OS X seseorang sementara Gentoo yang lain, atau bisa jadi ada hubungannya dengan bagaimana /etc/sudoerssetup.
Nemo157

aha! Anda benar - saya berakhir di sini bertanya-tanya mengapa saya .viminfohanya dapat diakses oleh root.
Ayrat

1

JIKA INI ADALAH KOMPUTER ANDA SENDIRI ... Saya tidak melihat alasan mengapa Anda tidak dapat menggunakan 'sudo vim', selain dari kasus tepi yang dicatat Denilson - yang mungkin membuat ~ / .viminfo Anda dimiliki oleh root.

Jika tidak - jika administrator sistem membatasi apa yang Anda bisa dan tidak bisa lakukan - per "man sudo": "pada kebanyakan sistem, Anda dapat mencegah shell lolos dengan fungsi noexec sudo. Lihat manual sudoers (5) untuk detailnya. "

Jadi dalam kasus ini, jika sysadmin Anda khawatir tentang potensi Anda menjalankan subshell sebagai root dari dalam vim, mereka dapat menggunakan kemampuan noexec. Tapi ... kembali ke kasus awal - jika ini adalah komputer ANDA, saya pikir Anda cukup aman menjalankan 'sudo vim'.


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.