Mengapa chmod (1) pada grup memengaruhi mask ACL?

Saya mencoba memahami perilaku Unix ini (yang kebetulan saya uji pada Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Perhatikan bahwa perintah chmod (1) telah memperbarui topeng ACL. Mengapa ini terjadi?

Halaman SunOS memiliki yang berikut untuk dikatakan:

Jika Anda menggunakan perintah chmod (1) untuk mengubah izin pemilik grup file pada file dengan entri ACL, baik izin pemilik grup file dan topeng ACL diubah ke izin baru. Perlu diketahui bahwa izin ACL mask baru dapat mengubah izin efektif untuk pengguna dan grup tambahan yang memiliki entri ACL pada file.

Saya bertanya karena akan nyaman bagi saya jika chmod (1) tidak memiliki perilaku ini. Saya berharap bahwa dengan memahami mengapa ia melakukan apa yang dilakukannya, saya dapat merancang dengan lebih baik cara mengatur izin sistem file.

Ini akan tidak nyaman bagi Anda jika chmod()tidak memiliki perilaku ini.

Akan sangat merepotkan, karena hal-hal yang secara tradisional diharapkan orang untuk dikerjakan di Unix akan hancur. Perilaku ini bermanfaat bagi Anda, apakah Anda tahu itu.

Sayang sekali bahwa IEEE 1003.1e tidak pernah menjadi standar dan ditarik pada tahun 1998. Dalam praktiknya, empat belas tahun kemudian, standar yang digunakan oleh berbagai sistem operasi - mulai dari Linux hingga FreeBSD hingga Solaris - benar-benar diterapkan.

IEEE 1003.1e draft kerja # 17 membuat bacaan yang menarik, dan saya merekomendasikannya. Dalam lampiran B § 23.3 kelompok kerja memberikan alasan rinci, delapan halaman, untuk cara yang agak rumit bahwa POSIX ACL bekerja sehubungan dengan S_IRWXGbendera izin grup lama . (Perlu dicatat bahwa orang-orang TRUSIX memberikan analisis yang sama sepuluh tahun sebelumnya.) Saya tidak akan menyalin semuanya di sini. Baca alasannya dalam draft standar untuk detailnya. Berikut adalah précis yang sangat singkat :

• Manual SunOS salah. Itu harus dibaca

  Jika Anda menggunakan chmod(1)perintah untuk mengubah izin pemilik grup file pada file dengan entri ACL, baik izin pemilik grup file atau topeng ACL diubah ke izin baru.

  Ini adalah perilaku yang dapat Anda lihat terjadi , terlepas dari apa yang dikatakan halaman manual saat ini, dalam pertanyaan Anda. Itu juga perilaku yang ditentukan oleh standar draft POSIX. Jika a CLASS_OBJ(Sun's dan TRUSIX's terminology for ACL_MASK) entri kontrol akses ada, kelompok bit dari chmod()set itu, kalau tidak mereka mengatur GROUP_OBJentri kontrol akses.

• Jika ini tidak terjadi, aplikasi yang melakukan berbagai hal standar dengan `chmod ()`, mengharapkannya berfungsi sebagai `chmod ()` secara tradisional bekerja pada Unix non-ACL lama, akan meninggalkan celah keamanan yang menganga atau melihat apa mereka mengira lubang keamanan menganga:

  • Aplikasi Unix tradisional berharap dapat menolak semua akses ke file, bernama pipa, perangkat, atau direktori chmod(…,000). Di hadapan ACL, ini hanya mematikan semua izin pengguna dan grup jika S_IRWXGpeta lama melakukannya CLASS_OBJ. Tanpa ini, mengatur izin file lama agar 000tidak memengaruhi entri USERatau apa pun GROUPdan pengguna lain, secara mengejutkan, masih memiliki akses ke objek.

    Mengubah bit izin file untuk sementara waktu tanpa akses dengan chmod 000dan kemudian mengubahnya kembali adalah mekanisme penguncian file yang lama, digunakan sebelum Unix mendapatkan mekanisme penguncian penasihat, yang - seperti yang Anda lihat - orang masih menggunakan hari ini .

  • Skrip Unix tradisional berharap dapat berjalan chmod go-rwxdan berakhir dengan hanya pemilik objek yang dapat mengakses objek. Sekali lagi - seperti yang Anda lihat - ini masih merupakan kebijaksanaan yang diterima dua belas tahun kemudian. Dan lagi, ini tidak bekerja kecuali tua S_IRWXGpeta untuk CLASS_OBJjika ada, karena jika tidak bahwa chmodperintah tidak akan mematikan setiap USERatau GROUPkontrol akses entri, yang mengarah ke pengguna selain pemilik dan non-memiliki kelompok mempertahankan akses ke sesuatu yang adalah diharapkan hanya dapat diakses oleh pemilik.

  • Sebuah sistem di mana bit izin terpisah dari dan anddiedit dengan ACL akan memerlukan flag izin file rwxrwxrwxdalam kebanyakan kasus, yang akan membingungkan heck out dari banyak aplikasi Unix yang mengeluh ketika mereka melihat apa yang mereka pikir dapat ditulis oleh dunia. barang.

    Suatu sistem di mana bit izin terpisah dari dan ordiedit dengan ACL akan memiliki chmod(…,000)masalah yang disebutkan sebelumnya.

Bacaan lebih lanjut

• Winfried Trümper (1999-02-28). Ringkasan tentang Posix.1e
• Komite Standar Aplikasi Portabel Masyarakat Komputer IEEE (Oktober 1997). Standar Draf untuk Teknologi Informasi — Antarmuka Sistem Operasi Portabel (POSIX) —Bagian 1: Antarmuka Program Aplikasi Sistem (API) - Amandemen #: Perlindungan, Audit dan Antarmuka Kontrol [Bahasa C] IEEE 1003.1e. Draft 17.
• Craig Rubin (1989-08-18). Dasar Pemikiran untuk Memilih Fitur Daftar Kontrol Akses untuk Sistem Unix . NCSC-TG-020-A. DIANE Publishing. ISBN 9780788105548.

Perilaku ini hanya berlaku untuk entri POSIX ACL. Alasan ini ada di sini adalah jika Anda memiliki folder dan di dalam folder itu terdapat file, Anda dapat acl sebagai rwx (misalnya) folder dan file. Jika izin grup dari file adalah rw- (yang mereka mungkin sebagai skenario khas) mask dengan demikian memberikan acl izin yang efektif dari rw- meskipun ACL secara eksplisit menunjukkan rwx.

Di sisi lain, direktori yang hampir selalu adalah + x memiliki izin ACL mask yang efektif juga mengizinkan + x.

Singkatnya, topeng ini pada dasarnya digunakan untuk membedakan izin antara file dan folder untuk set POSIX ACL sehingga file tidak menjadi executable padahal seharusnya tidak bisa.