Haruskah skrip yang memerlukan sudo gagal jika tidak memilikinya, atau gunakan sudo dan prompt?

26

Saya memiliki skrip yang memberi saya kendali yang baik atas kecerahan lampu latar saya dan sudoharus dijalankan. Ini pada dasarnya ini:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | tee $backlight

dan tinggal di ~/bin/backlight-adjust. Script memerlukan sudohak istimewa, karena tee $backlightmenulis ke lokasi yang istimewa. Jadi itu akan gagal jika tidak dijalankan sudo.

Pendekatan ini memiliki masalah, karena saya tidak bisa hanya berjalan sudo backlight-adjust, karena ~/bintidak ada di $PATHdalam sudolingkungan, hanya di lingkungan saya. Jadi saya harus menjalankan sudo env "PATH=$PATH" backlight-adjustatau yang serupa.

Atau, saya bisa menulisnya seperti ini:

backlight="/sys/class/backlight/acpi_video0/brightness"
echo $1 | sudo tee $backlight

dan minta saya untuk memasukkan kata sandi.

Pendekatan kedua bekerja lebih baik untuk saya karena saya tidak harus ingat untuk mengetikkan sudo; itu akan meminta saya. Dan aku bisa menjaga $PATHkeutuhanku. Secara keseluruhan ini terasa lebih nyaman, tetapi adakah alasan mengapa saya tidak boleh melakukannya dengan cara kedua?

(Saya menjalankan Xubuntu 14.04 dan shell saya GNU bash 4.2.45, jika itu membuat perbedaan.)

bash shell-script sudo

— John Feminella
sumber

Terima kasih atas koreksinya. Saya menjalankan Debian yang dimodifikasi (LMDE) dan saya sudobenar - benar membuat saya $PATHsecara default jadi saya tidak memiliki masalah ini.

— terdon

27

Secara pribadi, saya akan menggunakan pendekatan yang berbeda. Buat alias untuk skrip Anda. Tambahkan baris ini ke Anda ~/.bashrc(atau setara dengan shell lain)

alias backlight-adjust='sudo ~/bin/backlight-adjust'

Dengan begitu, Anda tidak perlu khawatir mengingat untuk menjalankannya sudodan Anda tidak perlu menambahkannya sudoke skrip. Ini akan sepenuhnya transparan bagi Anda dan hanya meminta kata sandi saat Anda mencoba dan menjalankannya backlight-adjust.

— terdon
sumber

Ini sepertinya pendekatan yang sangat masuk akal, dan yang berdampak minimal pada sistem lainnya. +1.

— John Feminella

@JohnFeminella Di sisi lain, jika Anda ingin berbagi skrip ini dengan orang lain, mereka akan membutuhkan alias juga. Secara pribadi, saya tidak melihat alasan untuk tidak memasukkan sudoskrip yang sebenarnya, terutama karena itu memungkinkan Anda untuk dengan mudah melihat elemen skrip mana yang benar-benar memerlukan izin root.

— Kyle Strand

@KyleStrand tidak, mereka tidak akan melakukannya. Perintah yang dipanggil oleh skrip hanya akan mengeluh tentang tidak memiliki akses.

— terdon

@terdon Saya menyadari bahwa saya bisa sedikit lebih jelas, tetapi mungkin Anda tahu apa yang saya maksud: penerima naskah akan menghadapi masalah yang sama yang awalnya dihadapi oleh penulis naskah, dan sebagai pembagi naskah yang teliti, penulis harus juga berbagi solusi pribadi mereka dengan dilema penggunaan khusus ini.

— Kyle Strand

@KyleStrand ya, tapi tidak ada masalah, satu-satunya masalah OP adalah bahwa dia tidak ingin "harus ingat untuk mengetikkan sudo" selain itu, skrip akan sangat portabel. Maksud saya adalah bahwa alias itu sepenuhnya opsional dan tidak menyelesaikan apa pun, itu hanya membuatnya lebih mudah digunakan.

— terdon

7

Saya tidak bisa melihat mengapa itu bisa salah --- walaupun saya biasanya lebih suka bahwa perintah tidak akan menanyakan hal-hal kepada saya, sehingga mereka dapat skrip. Anda dapat mengubah /etc/sudoersagar sudoberfungsi tanpa kata sandi.

Tapi ... kenapa tidak menambahkan

chgrp  one-of-your-groups-here /sys/class/backlight/acpi_video0/brightness     
chmod g+w /sys/class/backlight/acpi_video0/brightness

di Anda /etc/rc.localdan lupakan sudo?

(Di Ubuntu jika Anda dapat menggunakan sudoAnda berada di grup sudo , sehingga Anda dapat menggunakan chgrp sudo /sys...dan senang dengan itu.)

— Rmano
sumber

3

Atau, Anda bisa menambahkan

Defaults        env_keep +="PATH"

ke /etc/sudoersfile Anda .

— Mog
sumber

2

Anda menyatakan sudo backlight-sesuaikan, karena ~ / bin tidak dalam $ PATH di lingkungan sudo

Jadi mengapa bergantung pada itu? Saya pikir Anda hanya perlu mengubah jalur /home/user/bin/backlight-adjustitu dan itu akan berhasil.

Tapi saya sangat suka solusi Terdon menggunakan alias juga. Atau Anda dapat menempatkan skrip Anda di /usr/bin/dan itu akan tersedia untuk setiap pengguna (termasuk root)

— ExploWare
sumber

Ya, tapi itu menyebalkan. Kalau tidak, apa gunanya meletakkannya di $ PATH saya di tempat pertama? Juga, saya suka memilikinya ~/binkarena saat itu di bawah repositori dotfiles rumah saya, sehingga tetap dalam kontrol versi.

— John Feminella

@JohnFeminella omong-omong, tidak ada alasan untuk mengubah jalur, cukup gunakan -Ebendera untuk melestarikan lingkungan:sudo -E command

— terdon

@terdon Itu tidak berfungsi di Debian; itu ditimpa untuk alasan keamanan. Anda harus melewati variabel lingkungan secara eksplisit, seperti yang saya sebutkan dalam pertanyaan saya ( sudo env "PATH=$PATH" ...).

— John Feminella

1

Tidak dapat memberikan aturan umum ... jika skrip / program dirancang untuk melakukan konfigurasi ulang (misalnya printer) dan dipanggil oleh pengguna biasa, itu harus dilakukan. Kalau tidak, saya akan meninggalkan cukup baik sendirian: Jika pengguna biasa menjalankannya, gagal saja (baik sebagai hasil dari pemeriksaan eksplisit, atau hanya karena tidak diizinkan untuk melakukan sesuatu).

Hak istimewa yang tinggi harus dibagikan dengan hemat, jika sama sekali. Beralih ke hak istimewa yang lebih tinggi itu rumit, lebih baik serahkan ke ahli (yaitu, sudo(1)).

— vonbrand
sumber

0

Saya pribadi menggunakan sesuatu seperti ${SUDO}di skrip saya, sehingga penelepon dapat mengaturnya jika diperlukan, atau ${SUDO:-sudo}menggunakannya secara default.

Namun dalam kasus spesifik Anda, saya dengan jawaban yang diterima.

— mirabilos
sumber

-1

Letakkan skrip (tanpa sudo) di lokasi yang sesuai dengan pengguna, seperti /bin, lalu lakukan ini:

sudo chown root /bin/backlight-adjust
sudo chmod 4755 /bin/backlight-adjust

Ini berfungsi dengan mengatur flag setuid, yang berarti akan selalu dijalankan sebagai pemilik file. Untuk perinciannya silakan baca http://major.io/2007/02/13/chmod-and-the-mysterious-first-octet/ . Saya tidak benar-benar tahu banyak tentang bagaimana ini bekerja, saya hanya menemukan itu berdasarkan pada sesuatu yang saya pikir saya baca beberapa tahun yang lalu.

— AJMansfield
sumber

1

Script Shell tidak bisa lagi diatur, terima kasih Tuhan ... Ini adalah jawaban yang benar-benar jahat, Anda tahu. Secara keamanan, khususnya.

— mirabilos

@mirabilos Hanya berbahaya jika bendera tulis kelompok atau umum aktif. Risiko dengan setuid adalah siapa pun yang memiliki izin menulis untuk file tersebut dapat menjalankan apa pun yang mereka sukai seolah-olah mereka adalah pengguna, dan demikian pula izin menulis ini yang perlu dilindungi. 4755berarti selalu dieksekusi sebagai pemilik, pemilik dapat membaca, menulis, dan mengeksekusi, grup dapat membaca dan mengeksekusi, dan pengguna dapat membaca dan mengeksekusi, yang merupakan tingkat izin standar untuk hal-hal yang boleh diizinkan dilakukan oleh pengguna dengan izin root.

— AJMansfield

@mirabilos Dan gagasan bahwa skrip shell dengan setuid memperkenalkan lebih banyak kerentanan daripada binari dengan setuid hanya konyol; binari juga tidak kebal terhadap exploit ptrace, yang merupakan exploit utama yang mengambil keuntungan dari setuid.

— AJMansfield

2

Semua OS seperti Unix saat ini melarang skrip setuid. Ini hanya fakta. Tanyakan alasan mereka sendiri jika Anda tidak percaya kepada saya. Mulai dengan OpenBSD.

— mirabilos