Apakah ada alasan mengapa izin 'pemilik' ada? Tidak cukup izin grup?


21

Saya rasa saya lebih mengerti bagaimana izin file bekerja di Linux. Namun, saya tidak begitu mengerti mengapa mereka dibagi menjadi tiga level dan tidak menjadi dua.

Saya ingin menjawab masalah berikut:

  • Apakah ini desain yang disengaja atau patch? Yaitu - apakah izin pemilik / grup dirancang dan dibuat bersama dengan beberapa alasan atau apakah mereka datang satu demi satu untuk menjawab suatu kebutuhan?
  • Apakah ada skenario di mana pengguna / grup / skema lain berguna tetapi grup / skema lainnya tidak cukup?

Jawaban untuk yang pertama harus mengutip buku teks atau papan diskusi resmi.

Use case yang saya pertimbangkan adalah:

  • file pribadi - sangat mudah diperoleh dengan membuat grup per pengguna, sesuatu yang sering dilakukan seperti pada banyak sistem.
  • memungkinkan hanya pemilik (mis. layanan sistem) untuk menulis ke file, hanya memperbolehkan grup tertentu untuk membaca, dan menolak semua akses lainnya - masalah dengan contoh ini adalah bahwa begitu persyaratan untuk sebuah grup memiliki akses tulis, pengguna / group / lainnya gagal dengan itu. Jawaban untuk keduanya menggunakan ACL, dan tidak membenarkan, IMHO, keberadaan izin pemilik.

NB Saya telah memperbaiki pertanyaan ini setelah pertanyaan ditutup di superuser.com .

EDIT dikoreksi "tetapi skema grup / pemilik tidak akan cukup" menjadi "... grup / lainnya ...".


1
Saya tidak begitu mengerti mengapa menurut Anda izin grup sudah cukup. Bayangkan sebuah situasi di mana Anda ingin memungkinkan pengembang Anda memiliki file pribadi mereka sendiri (konfigurasi, dll), tetapi juga ingin memungkinkan mereka untuk berbagi kode antara satu sama lain. Memiliki devsgrup memungkinkan untuk ini.
Chris Down

@ChrisDown Dia mengatakan Anda akan membuat pengguna foomenjadi anggota grup foodan devs, dan menetapkan file yang dibagikan ke devgrup dan file pribadi ke foogrup
Michael Mrozek

4
Ketika Anda berada di sana, mengapa memiliki izin dunia alih-alih hanya sebuah grup 'semua orang' yang menjadi anggota? Jawabannya adalah bahwa pengaturan izin pengguna / grup / lainnya ditemukan sebelum ACL.
Random832

Jawaban:


24

Sejarah

Awalnya, Unix hanya memiliki izin untuk pengguna yang memiliki, dan untuk pengguna lain: tidak ada grup. Lihat dokumentasi Unix versi 1, khususnya chmod(1). Jadi kompatibilitas ke belakang, jika tidak ada yang lain, memerlukan izin untuk pengguna yang memiliki.

Grup datang kemudian. ACL yang memungkinkan melibatkan lebih dari satu grup dalam izin file datang jauh kemudian.

Kekuatan ekspresif

Memiliki tiga izin untuk file memungkinkan izin yang lebih halus daripada hanya memiliki dua, dengan biaya yang sangat rendah (jauh lebih rendah daripada ACL). Misalnya, file dapat memiliki mode rw-r-----: hanya dapat ditulis oleh pengguna yang memiliki, dapat dibaca oleh grup.

Kasus penggunaan lain adalah executable setuid yang hanya dapat dieksekusi oleh satu grup. Misalnya, program dengan mode yang rwsr-x---dimiliki oleh root:adminhanya memungkinkan pengguna dalam admingrup untuk menjalankan program itu sebagai root.

"Ada izin yang tidak bisa diungkapkan oleh skema ini" adalah argumen yang buruk untuk menentangnya. Kriteria yang berlaku adalah, apakah ada cukup banyak kasus yang dapat diungkapkan yang membenarkan biaya? Dalam hal ini, biayanya minimal, terutama mengingat alasan lain untuk pengguna / grup / triptych lainnya.

Kesederhanaan

Memiliki satu grup per pengguna memiliki overhead manajemen yang kecil tetapi tidak signifikan. Adalah baik bahwa kasus yang sangat umum dari file pribadi tidak tergantung pada ini. Aplikasi yang membuat file pribadi (misalnya program pengiriman email) tahu bahwa semua yang perlu dilakukan adalah memberikan file mode 600. Tidak perlu menelusuri database grup untuk mencari grup yang hanya berisi pengguna - dan apa yang harus dilakukan jika tidak ada grup seperti itu atau lebih dari satu?

Datang dari arah lain, misalkan Anda melihat file dan Anda ingin mengaudit izinnya (yaitu memeriksa apakah itu yang seharusnya). Ini jauh lebih mudah ketika Anda bisa "hanya dapat diakses oleh pengguna, baik, berikutnya" daripada ketika Anda perlu menelusuri definisi grup. (Kompleksitas semacam itu adalah kutukan sistem yang banyak menggunakan fitur-fitur canggih seperti ACL atau kemampuan.)

Orthogonality

Setiap proses melakukan akses sistem file sebagai pengguna tertentu dan grup tertentu (dengan aturan yang lebih rumit tentang kesatuan modern, yang mendukung kelompok tambahan). Pengguna digunakan untuk banyak hal, termasuk pengujian untuk root (uid 0) dan izin pengiriman sinyal (berbasis pengguna). Ada simetri alami antara membedakan pengguna dan grup dalam izin proses dan membedakan pengguna dan grup dalam izin sistem file.


Jawaban yang sangat bagus, dan saya senang belajar tentang pria yang lebih tua. Namun, saya memiliki beberapa keraguan tentang apa yang Anda katakan. Sistem yang lebih sederhana, yang sebenarnya bisa melakukan hampir (jika tidak persis) sebanyak ACL, membiarkan setiap izin 'rwx' membawa grup (daripada sebaliknya). Artinya, Anda akan memiliki grup baca, grup tulis, dan grup eksekusi. Jika benar-benar diperlukan untuk tujuan OS, Anda dapat melampirkan pemilik ke file. Dengan begitu Anda juga dapat menentukan grup 'pemilik' khusus dan grup 'semua orang'. Selain hierarki, saya pikir ini mencakup segalanya, termasuk kesederhanaan dan ortogonalitas.
Yuval

1
@Yuval Apa yang Anda gambarkan adalah sistem ACL - sama seperti Linux, kecuali tanpa kemampuan langsung untuk memberikan izin kepada pengguna.
Gilles 'SANGAT berhenti menjadi jahat'

Itu mungkin. Apa yang saya coba tekankan adalah bahwa saat ini setiap catatan file memegang dua ID (grup, pemilik) dan bitmask. Bukankah lebih efektif (lagi, argumen biaya / keuntungan) untuk hanya memegang empat ID? (jalankan grup, baca grup, tulis grup, pemilik)
Yuval

@Yuval Mengapa empat ID? Itu akan jauh lebih membatasi daripada ACL (karena Anda akan memerlukan root untuk mendefinisikan grup untuk setiap set), dan hampir tidak ada yang lebih fleksibel daripada izin unix saat ini (membedakan membaca dari mengeksekusi sangat jarang, dan untuk menulis Anda sering ingin persatuan kelompok baca dan kelompok tulis). Jika Anda mengizinkan daftar grup untuk setiap izin, dan daftar pengguna untuk ukuran yang baik (karena tidak selalu ada grup yang tepat, tidak semua sistem memiliki grup per pengguna), pada dasarnya Anda mendapatkan Solaris / Linux ACLs.
Gilles 'SANGAT berhenti menjadi jahat'

Anda berpendapat bahwa apa yang saya jelaskan adalah ACL, tetapi ini berarti bahwa skema izin Linux saat ini adalah ACL yang cacat, yang diizinkan untuk hanya memiliki satu catatan pengguna, satu catatan grup, dan satu catatan untuk Semua Orang (untuk menggunakan istilah Windows). Saya menyarankan untuk memodifikasi cacat dengan menata ulang semantik. Daripada meresepkan entitas, tentukan izin. Ini mungkin bagaimana ACL tradisional diterapkan - saya tidak tahu. Intinya adalah, itu datang sebagai biaya minimal, dalam hal penyimpanan dan kesederhanaan, dibandingkan dengan keadaan saat ini, masih ortogonal, tetapi dengan kekuatan ekspresif penuh ACL.
Yuval

10

Apakah ini desain yang disengaja atau patch? Yaitu - apakah izin pemilik / grup dirancang dan dibuat bersama dengan beberapa alasan atau apakah mereka datang satu demi satu untuk menjawab suatu kebutuhan?

Izin pengguna / grup / lainnya pada file adalah bagian dari desain Unix asli.

Apakah ada skenario di mana skema pengguna / grup / lainnya berguna tetapi skema grup / pemilik tidak akan cukup?

Ya, hampir setiap skenario yang saya bayangkan di mana keamanan dan kontrol akses penting.

Contoh: Anda mungkin ingin memberikan beberapa binari / skrip pada sistem akses khusus eksekusi other, dan tetap membatasi akses baca / tulis root.

Saya tidak yakin apa yang ada dalam pikiran Anda untuk model izin sistem file yang hanya memiliki izin pemilik / grup. Saya tidak tahu bagaimana Anda bisa memiliki sistem operasi yang aman tanpa adanya otherkategori.

EDIT: Misalkan yang Anda maksud di sini group/otheradalah izin yang diperlukan, maka saya sarankan mencari beberapa cara untuk mengelola kunci kriptografi atau cara yang hanya pengguna yang tepat dapat mengakses gulungan surat mereka. Ada kasus-kasus di mana kunci pribadi mungkin memerlukan user:userkepemilikan yang ketat tetapi kasus-kasus lain di mana masuk akal untuk memberikannya user:groupkepemilikan.

file pribadi - sangat mudah diperoleh dengan membuat grup per pengguna, sesuatu yang sering dilakukan seperti pada banyak sistem.

Memang ini mudah dilakukan, tetapi sama mudahnya dengan keberadaan suatu otherkelompok ...

memungkinkan hanya pemilik (mis. layanan sistem) untuk menulis ke file, hanya memperbolehkan grup tertentu untuk membaca, dan menolak semua akses lainnya - masalah dengan contoh ini adalah bahwa begitu persyaratan untuk sebuah grup memiliki akses tulis, pengguna / group / lainnya gagal dengan itu. Jawaban untuk keduanya menggunakan ACL, dan tidak membenarkan, IMHO, keberadaan izin pemilik.

Saya telah menyoroti bagian dari pernyataan Anda yang tampaknya menegaskan kembali poin saya tentang perlunya logis untuk otherkategori dalam izin sistem file Unix.

Desain sistem file seperti yang Anda renungkan (dari apa yang bisa saya katakan) mungkin tidak aman atau sulit digunakan. Unix dirancang oleh beberapa orang yang sangat pintar, dan saya pikir model mereka memberikan keseimbangan keamanan dan fleksibilitas terbaik.


1
Saya pikir "grup / pemilik" adalah kesalahan ketik yang dimaksudkan sebagai "grup / lainnya"
Random832

Ah, kamu mungkin benar! Dalam hal ini, saya akan menambahkan contoh-contoh lain.
Charles Boyd

3
Seperti yang dapat Anda baca The UNIX Time-Sharing System, ditulis oleh Dennis M. Ritchie dan Ken Thomson pada tahun 1974, awalnya, ada 7 bit untuk izin: Also given for new files is a set of seven protection bits. Six of these specify independently read, write, and execute permission for the owner of the file and for all other users.(Bit ketujuh adalah setuidbit).
Carlos Campderró

4

Apakah ini desain yang disengaja atau patch? Yaitu - apakah izin pemilik / grup dirancang dan dibuat bersama dengan beberapa alasan atau apakah mereka datang satu demi satu untuk menjawab suatu kebutuhan?

Ya ini adalah desain yang disengaja yang telah hadir di UNIX sejak awal. Itu diimplementasikan pada sistem di mana memori diukur dalam KB dan CPU sangat lambat menurut standar saat ini. Ukuran dan kecepatan pencarian seperti itu penting. ACL akan membutuhkan lebih banyak ruang dan lebih lambat. Secara fungsional, everyonegrup diwakili oleh bendera keamanan lainnya.

Apakah ada skenario di mana skema pengguna / grup / lainnya berguna tetapi skema grup / pemilik tidak akan cukup?

Izin yang biasa saya gunakan untuk akses file adalah: (Saya menggunakan nilai bit untuk kesederhanaan dan karena itulah cara saya biasanya mengaturnya.)

  • 600atau 400: Akses hanya pengguna (dan ya saya memberikan akses hanya baca ke pengguna).
  • 640atau 660: Akses pengguna dan grup.
  • 644, 666atau 664: Pengguna, grup, dan akses lainnya. Skema izin dua tingkat apa pun hanya dapat menangani dua kasus ini. Yang ketiga akan membutuhkan ACL.

Untuk direktori dan program yang biasa saya gunakan:

  • 700atau 500: Akses hanya pengguna
  • 750atau 710: Akses hanya grup
  • 755, 777, 775, Atau 751: Pengguna, kelompok, dan akses lainnya. Komentar yang sama berlaku untuk file.

Di atas adalah yang paling umum digunakan, tetapi bukan daftar lengkap pengaturan izin yang saya gunakan. Izin di atas dikombinasikan dengan grup (kadang-kadang dengan bit grup lengket pada direktori) telah mencukupi dalam semua kasus di mana saya mungkin menggunakan ACL.

Seperti yang telah dicatat di atas, sangat mudah untuk mendaftar izin dalam daftar direktori. Jika ACL tidak digunakan, saya dapat mengaudit izin akses hanya dengan daftar direktori. Ketika saya bekerja dengan sistem berbasis ACL, saya merasa sangat sulit untuk memverifikasi atau mengaudit izin.


3

Sistem izin pengguna / grup / lainnya dirancang sebelum ACL ditemukan. Ini kembali ke hari-hari awal UNIX, jadi Anda tidak bisa mengatakan masalah harus diselesaikan dengan ACL. Bahkan jika konsep ACL tampak jelas, itu akan melibatkan jumlah overhead tambahan [untuk hari] yang signifikan untuk menyimpan dan mengelola sejumlah variabel informasi izin dengan setiap file, daripada jumlah yang tetap.

Menggunakan ACL untuk semuanya juga berarti Anda tidak memiliki subset yang jelas tentang informasi izin yang dapat ditampilkan "sekilas". Output untuk ls -lmenunjukkan izin standar (pengguna / grup / lainnya), nama pengguna dan grup, dan notasi tambahan (misalnya +atau @tanda) pada entri yang memiliki ACL yang terkait dengannya, semuanya dalam satu baris. Sistem Anda akan membutuhkannya untuk mengidentifikasi kelompok "dua teratas" di ACL untuk menyediakan fungsionalitas yang setara.

Sebagai poin tambahan, file masih harus memiliki pemilik dalam model UNIX karena UNIX ACL tidak menyediakan siapa yang diizinkan untuk memodifikasi ACL.

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.