Tujuan izin seperti 0111 atau 0333


17

Apa tujuan dari izin Linux seperti 111 atau 333 (yaitu pengguna dapat mengeksekusi , tetapi tidak dapat membaca file), jika kemampuan untuk mengeksekusi tidak secara otomatis menyiratkan kemampuan untuk membaca?


1
Apakah Anda memiliki contoh untuk pengaturan seperti itu? Saya pikir kamu benar. Anda tidak dapat menjalankan apa yang tidak dapat Anda baca. Kombinasi ini hanya teoretis dalam ruang izin antara 0000 dan 0777. Perhatikan bahwa awalan 0 harus ditambahkan untuk menunjukkan basis oktal dari angka tersebut.
ikrabbe

6
Kecuali itu skrip (mis. Shell-script), Anda sebenarnya tidak perlu izin baca untuk menjalankan perintah. Eksekusi "normal" - mis. su, bash atau vi - hanya perlu bit executable yang akan ditetapkan, untuk memungkinkan pengguna untuk menjalankannya. File yang tidak bisa dibaca, tidak bisa disalin . Jadi dengan tidak mengizinkan pengguna untuk menyalin perintah penting keamanan (seperti su), ia dicegah membuat salinannya sendiri - dan juga dari mencoba membongkar itu. * BSD memiliki beberapa perintah dengan eksekusi tetapi tanpa izin baca.
Baard Kopperud

Jawaban:


25

Saya bermain dengannya dan ternyata, izin exec tidak menyiratkan izin baca. Binari dapat dieksekusi tanpa dapat dibaca:

$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw 
hello world
$ cat hw
/bin/cat: hw: Permission denied

Saya tidak bisa mengeksekusi skrip, kecuali mereka memiliki bit izin baca dan exec pada:

$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh 
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied

4
Ini benar karena contoh kedua menggunakan #! untuk memulai karena merindukan ELF-header dan karenanya membutuhkan file agar dapat dibaca untuk menebak yang dapat dieksekusi untuk menggunakannya. Ini adalah situasi umum di mana Anda ingin melindungi konten file agar tidak disalin ke lokasi lain. Manajer lisensi adalah contoh umum di mana Anda akan melihat ini.
hspaan

1
Perhatikan bahwa Anda masih dapat membaca biner yang dapat dijalankan: unix.stackexchange.com/a/34294
小 太郎

6
@hspaans: Shebang ditangani oleh kernel, dan kernel tidak peduli tentang hal-hal kecil yang aneh seperti izin. Ini adalah shell (atau interpreter) yang membutuhkan akses baca. Kernel berjalan (katakanlah) /bin/bash hw.sh, dan kemudian bash mencoba membuka hw.shuntuk membaca (dan gagal).
Kevin

2
Saya sangat berharap bahwa kernel tidak peduli dengan perizinan. Tidak ada yang lain. Apa yang dimaksud dengan kalimat menakutkan dalam posting @ Kevin adalah bahwa kernel hanya memerlukan izin eksekusi untuk mengeksekusi file, terlepas dari apakah mereka menggunakan shebang.
Emil Jeřábek mendukung Monica

2
@ EmilJeřábek Kernel peduli terhadap izin ketika memutuskan apa yang dapat dilakukan proses aplikasi. Tetapi karena itu adalah komponen yang mengimplementasikan izin, ia juga dapat mengabaikannya secara internal. Jadi itu bisa membaca baris shebang ketika menentukan bagaimana mengeksekusi file yang ditafsirkan, atau membaca isi file biner yang hanya menjalankan ke dalam memori.
Barmar 8-15

16

masuk akal untuk direktori, misalnya jika Anda menyimpan (rahasia) executable di direktori tertentu dan kemudian memungkinkan pengguna memanggil file-file itu tanpa dapat melihat konten direktori (tetapi mengetahui bahwa ada file tertentu setelah Anda memberi tahu mereka!). 333 dibandingkan dengan 111 memungkinkan menulis / menghapus file ke / dari direktori tersebut tanpa dapat melihat isi direktori.


5
Di Uni saya, izin-izin itu digunakan untuk menjatuhkan tugas ke direktori tanpa siswa melihat salah satu dari yang lain berfungsi. Dosennya adalah skool tua.
DarkHeart

@DarkHeart Menarik. Saya harap Anda harus menambahkan komponen acak ke nama file, karena jika tidak, jika itu bukan insentif untuk mencoba dan menyalin dari teman sekelas Anda, saya tidak tahu apa itu.
PSkocik

5

Jelas tidak semua kombinasi bermanfaat, tetapi untuk mengambil kombinasi yang Anda sebutkan secara spesifik ... Anda sebenarnya tidak perlu readizin untuk mengeksekusi file - hanya executeizin - kecuali file yang dimaksud adalah skrip (mis. Skrip shell ( .sh), perl-script ( .pl) dan sebagainya). Binari normal dapat dijalankan hanya dengan executeizin. Pada * BSD-systmes, beberapa executable memberikan executeizin tanpa readpermisson, terutama pada perintah "keamanan-penting" - mis su.

Jadi mengapa tidak memberikan pengguna read-permission (dan hanya execute-permisson)? Karena file yang tidak dapat dibaca oleh pengguna, juga tidak dapat disalin oleh pengguna itu! Menghapus readizin, mencegah pengguna membuat salinan executable "pribadi" mereka sendiri - yang nantinya bisa disalahgunakan (misalnya didapat SUID=root on).

Dan tidak memiliki write-permission, mencegah file agar tidak dihapus dengan benar.

Pikiran Anda, tidak memberikan read-tidak write-permintaan kepada pemilik agak jarang, tetapi kadang-kadang mungkin ide yang baik untuk mencegah bahkan ownerdari hanya menghapus file. Tentu saja owner- belum lagi root- mungkin selalu menghindari langkah-langkah seperti itu, jika tidak dengan cara lain, maka cukup dengan chmodizin pada file tersebut.


"Mungkin ide yang bagus untuk mencegah bahkan ownerdari hanya menghapus file." - kecuali bahwa Anda tidak memerlukan izin apa pun pada file (baca, tulis, atau jalankan) untuk menghapusnya.
Celada

File executable saja dapat digunakan misalnya jika file yang dapat dieksekusi menanamkan kata sandi basis data yang digunakan saat dijalankan untuk menyambungkan ke basis data dan melakukan tugasnya tetapi itu tidak selalu ingin mengungkapkan kata sandi.
Celada

@Celada, ini adalah pertanyaan lama, tetapi bukankah pendekatan seperti itu rentan terhadap penumpukan memori melalui pencarian wilayah memori offset /proc/${PID}/mapsdan kemudian membaca bagian memori yang relevan dari /proc/${PID}/mem? Atau apakah membatasi izin pada file yang dapat dieksekusi juga membatasi izin baca pada bagian yang relevan di memori selama eksekusi? (Yang terakhir tampaknya tidak mungkin, IMO.)
Spencer D
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.