penjelasan tentang chown (1) POSIX spec

Spesifikasi POSIX untuk chownutilitas menyebutkan di bagian rasionalnya tentang chown user:groupsintaks (sebelumnya chown user.group) (penekanan milik saya):

Metode 4.3 BSD menentukan pemilik dan grup dimasukkan dalam volume POSIX.1-2008 ini karena:

• Ada kasus di mana kondisi akhir yang diinginkan tidak dapat dicapai menggunakan utilitas chgrp dan chown (yang hanya mengubah ID pengguna). (Jika pemilik saat ini bukan anggota dari grup yang diinginkan dan pemilik yang diinginkan bukan anggota dari grup saat ini, fungsi chown () dapat gagal kecuali jika pemilik dan grup diubah pada saat yang sama.)

Saya pikir user:groupsintaks adalah hal yang mudah. Sekarang hal di atas menyiratkan ada hal-hal yang dapat Anda lakukan dengan chown user:groupyang tidak dapat Anda lakukanchgrp group; chown user

Sekarang teks itu tidak masuk akal bagi saya. Di 4.3BSD, hanya root yang bisa mengubah pemilik file sehingga dalam hal apa pun tidak ada batasan dalam apa yang bisa ia lakukan.

SysV dan beberapa sistem lainnya memungkinkan (atau digunakan untuk mengizinkan) pemilik file untuk mengubah pengguna dan grup file menjadi apa pun, tetapi bahkan dalam sistem tersebut, teks di atas tidak masuk akal bagi saya. OK, jika seseorang melakukan a chown someone-else the-file, ia tidak dapat melakukannya chgrp something-else the-filesetelah itu karena ia bukan lagi pemilik file, tetapi tidak ada yang mencegahnya melakukan yang chgrppertama (tetap menjadi pemilik file) dan chownsetelahnya, dan bukan itu yang teks di atas persis mengatakan.

Saya tidak mengerti apa dan pemilik yang diinginkan bukan anggota dari grup saat ini yang ada hubungannya dengan masalah tersebut.

Jadi apa saja kondisi di mana fungsi chown () bisa gagal kecuali jika pemilik dan grup diubah pada saat yang sama , dan pada sistem apa?

The Microsoft Interix Unix subsistem (sekarang pensiun) untuk kernel NT yang ditangani kecil yang berbeda dengan pengguna dan kelompok hak akses dari beberapa orang lain lakukan:

Informasi pengguna dan grup disimpan dalam database Access Keamanan . Baik pengguna dan grup disimpan dalam database yang sama, tetapi grup dan nama pengguna harus unik; tidak ada grup yang dapat memiliki nama pengguna dan sebaliknya. (Basis data ini menggantikan /etc/passwddan /etc/groupsfile dalam UNIX.) Pengguna dan grup dibuat menggunakan metodologi Windows yang sesuai (Manajer Pengguna, Pengguna dan Komputer Direktori Aktif, atau Pengguna dan Grup Lokal) atau dengan net userperintah Win32 . (Contoh skrip shell untuk membuat dan menghapus pengguna termasuk dalam direktori /usr/examples/admin.) Pengguna dapat menjadi bagian dari banyak grup.

Berikut adalah beberapa kutipan manual yang lebih spesifik:

Di Windows, pengguna atau grup dapat memiliki objek. Ini berbeda dari UNIX, di mana hanya pengguna yang memiliki objek.

Windows mengidentifikasi semua pengguna dan grup secara internal dengan menggunakan pengidentifikasi keamanan (SID) . Algoritma hashing menghasilkan nilai SID yang unik; tidak ada dua pengguna atau grup yang memiliki SID yang sama.

Pengguna dan grup yang memiliki izin untuk mengakses objek diidentifikasi oleh SID mereka. Semua objek yang dapat diamankan oleh Windows memiliki daftar kontrol akses diskresioner (DACL), yang terdiri dari entri terpisah yang disebut entri kontrol akses (ACE). ACE mencakup dua informasi penting: SID pengguna atau grup, dan deskripsi tentang seberapa banyak akses yang dimiliki masing-masing pengguna atau grup ke suatu objek.

CHGRP

... Ubah ID grup untuk file ... pengguna yang memanggil chgrp (1) harus milik grup yang ditentukan dan menjadi pemilik file, atau memiliki hak istimewa yang sesuai.

CHOWN

... Pemilik dan operan grup keduanya opsional; Namun, seseorang harus ditentukan. Jika operan grup ditentukan, itu harus didahului dengan titik dua (:).

Pemilik dapat ditentukan dengan ID pengguna numerik atau nama pengguna. Jika nama pengguna juga merupakan ID pengguna numerik, operan digunakan sebagai nama pengguna. Grup dapat berupa ID grup numerik atau nama grup. Jika nama grup juga merupakan ID grup numerik, operan digunakan sebagai nama grup.

Untuk alasan keamanan, kepemilikan file hanya dapat diubah dengan proses dengan hak istimewa yang sesuai.

Saat saya membacanya, itu berarti bahwa jika akun pengguna Anda milik grup Windows dengan hak istimewa yang cukup untuk memodifikasi izin file yang dimiliki oleh grup itu, maka dimungkinkan untuk secara efektif chgrpfile itu di luar kendali akun pengguna Anda. Ini berarti kontrol yang lebih rendah daripada yang mungkin Anda miliki dengan chowndan user:groupparameter eksplisit . Dalam konteks itu tanpa kemungkinan menyatakan user: dan :group Anda tidak akan pernah bisa mencapai hasil yang sama seperti sebaliknya.

Berikut ini adalah tautan ke tampilan terperinci tentang bagaimana Interix berinteraksi dengan Windows ACL dengan fokus pada bagaimana pengetahuan tersebut mungkin berlaku untuk sistem file Samba pada varian Unix lainnya.

Berikut ini tautan ke dokumen Solaris yang sekarang sudah usang yang menjelaskan tentang merdu rstchownyang ...

Menunjukkan apakah semantik POSIX untuk chown(2)panggilan sistem berlaku ...

Rupanya, jika parameter diatur ke nilai 0...

... mematikan semantik POSIX membuka potensi berbagai celah keamanan. Ini juga membuka kemungkinan pengguna mengubah kepemilikan file ke pengguna lain dan tidak dapat mengambil kembali file tanpa intervensi dari pengguna atau administrator sistem.

Opsi seperti itu tidak membatalkan kesesuaian POSIX Solaris . Hanya saja itu adalah opsi yang memenuhi syarat sebagai konforman :

Meskipun semua implementasi yang sesuai dengan POSIX.1-2008 mendukung semua fitur yang dijelaskan di bawah ini, mungkin ada prosedur konfigurasi yang bergantung pada sistem atau file yang dapat menghapus atau memodifikasi salah satu atau semua fitur ini. Konfigurasi seperti itu tidak boleh dilakukan jika kepatuhan yang ketat diperlukan.

Konstanta simbolik berikut harus didefinisikan dengan nilai selain -1. Jika konstan didefinisikan dengan nilai nol, aplikasi harus menggunakan sysconf(), pathconf()atau fpathconf()fungsi, atau getconfutilitas, untuk menentukan fitur yang ada pada sistem pada saat itu atau untuk pathname tertentu dalam pertanyaan.

_POSIX_CHOWN_RESTRICTED

Penggunaan chown()dibatasi untuk suatu proses dengan hak istimewa yang sesuai, dan untuk mengubah ID grup dari file hanya ke ID grup yang efektif dari proses atau ke salah satu ID grup tambahannya.

Fungsi chown()sistem - yang merupakan panggilan sistem terdokumentasi yang dibuat oleh utilitas shell chowndan chgrp- adalah ditentukan untuk gagal karena berbagai alasan. Diantara mereka:

EACCES Izin pencarian ditolak pada komponen awalan jalur.

ELOOP Sebuah loop ada di tautan simbolik yang ditemui selama resolusi argumen path.

EPERM ID pengguna yang efektif tidak cocok dengan pemilik file, atau proses panggilan tidak memiliki hak yang sesuai dan _POSIX_CHOWN_RESTRICTED menunjukkan bahwa hak istimewa tersebut diperlukan.

Namun, perilaku pemberian hak modifikasi izin kepada pengguna non-root tidak pernah unik bagi Solaris. Ada cakupan sangat baik - jika agak tanggal - izin file Unix dalam posting forum ini di mana penulis menyatakan:

Awalnya, Unix mengizinkan pemilik file untuk memberikan file. Pemilik file dapat mengubah pemiliknya menjadi orang lain. Tidak ada cara bagi pengguna non-root untuk membatalkan operasi ini ... BSD [kemudian] dihapus chowndari pengguna non-root ... [sebagian karena] ... itu menerapkan kuota disk yang dapat membatasi berapa banyak ruang disk yang pengguna dapat memiliki dalam sistem file ... Pengguna nakal dapat memberikan file besar untuk menyelinap melewati kuota.

Saat ini, tidak mudah untuk mengatakan apakah non-root dapat chownmembuat file. Banyak versi Unix memungkinkan keduanya perilaku ...

Pos mailing list lain yang bagus - dan yang lebih baru - mengutip ini dan berlanjut:

Standarnya dengan sebagian besar OS adalah untuk chowndibatasi hanya untuk root. Dan ada konsensus bahwa itu harus tetap seperti ini untuk pertimbangan keamanan. Jika pengguna non-root tidak mengubah pemilik file dan setiap bit eksekusi aktif, SUIDdan SGIDbit harus dibersihkan. Ini mungkin atau mungkin tidak terjadi dengan root.

Saya pikir paragraf terakhir mengatakannya dengan baik.

Artikel itu juga referensi CAP_CHOWNuntuk mengendalikan fasilitas itu di Linux (yang seharusnya hanya mempengaruhi POSIX_CHOWN_RESTRICTEDperilaku) . Ada jugaCAP_FOWNER kemampuan, itu sedikit berbeda dalam perilaku.

Dan seperti yang Anda tunjukkan pada tahun 2003 :

Perhatikan bahwa setidaknya pada HPUX, Anda dapat mengubah pemilik file Anda ( rootmisalnya) bahkan jika Anda bukan pengguna yang dilindungi hak cipta ...

... yang tergantung pada konfigurasi setprivgroup parameter .

Dalam kasus apa pun di mana pengguna non-root dapat memanipulasi file-izin itu dapat dibayangkan, seperti yang disebutkan dalam alasan yang dikutip dalam pertanyaan Anda, bahwa pengguna mungkin chownmemiliki file yang dimiliki pengguna sehingga dimiliki oleh pengguna lain. Jika kepemilikan grup file dan grup chownpengguna tidak sejajar, maka pengguna tidak lagi dapat memodifikasi file itu.

Dalam skenario ini chown maka chgrp akan gagal karena pengguna tidak lagi memiliki izin untuk mengubah izin file itu, sedangkan chown user:group- selama grup berada di antara pengguna sendiri - akan berhasil.

Ada mungkin banyak situasi niche lain yang mungkin mengakibatkan sama, yang mungkin termasuk direktori lengket dan / atau setgid bit, file sistem dan / atau daftar akses kontrol implementasi khusus. Utas ini menarik, misalnya. Permutasi yang tak terhitung jumlahnya jauh melampaui genggaman lemah saya sendiri - itulah sebabnya mengapa jawaban ini digunakan. Jika Anda membaca ini, Anda yakin itu layak untuk ditingkatkan, dan Anda yakin Anda tahu caranya - silakan lakukan .

Ada juga dokumentasi yang luas tentang berbagai efek yang mungkin terjadi dari izin file, traversal pohon, dan tautan simbolik yang mungkin berdampak pada kegagalan yang serupa sehubungan dengan aplikasi -Recursive di chownsini:

Dari judul bagian POSIX XRAT, Domain Ketiga dan Keempat :

Secara umum, pengguna yang menentukan opsi untuk traversal hierarki file ingin beroperasi pada hierarki fisik tunggal, dan karenanya tautan simbolik, yang mungkin merujuk file di luar hierarki, diabaikan. Sebagai contoh, file pemilik chown adalah operasi yang berbeda dari perintah yang sama dengan opsi -R yang ditentukan. Dalam contoh ini, perilaku perintah chown owner filedijelaskan di sini, sedangkan perilaku perintahchown -R file pemilik dijelaskan di domain ketiga dan keempat.

... Ada masalah keamanan dengan default ke jalan logis. Secara historis, chown -Rfile pengguna perintah telah aman untuk superuser karena setuid dan setgid bit hilang ketika kepemilikan file diubah. Jika jalannya logis, mengubah kepemilikan tidak lagi aman karena pengguna mungkin telah memasukkan tautan simbolis yang menunjuk ke file apa pun di struktur pohon. Sekali lagi, ini akan mengharuskan penambahan opsi untuk perintah yang melakukan hierarki traversal menjadi tidak langsung melalui tautan simbolik, dan skrip historis yang melakukan jalan rekursif akan langsung menjadi masalah keamanan. Meskipun ini sebagian besar merupakan masalah bagi administrator sistem, lebih baik tidak memiliki standar yang berbeda untuk kelas pengguna yang berbeda.

...

Di 4.3 BSD, chgrpselama traversal pohon mengubah grup tautan simbolik, bukan target. Tautan simbolik dalam 4.4 BSD tidak memiliki pemilik, grup, mode, atau atribut file sistem UNIX standar lainnya.

Dan dari chgrphalaman POSIX yang tepat ada ini yang menunjuk pada kemungkinan -Rtindakan ecursive yang tidak lengkap , atau setidaknya apa yang dulu :

Versi Sistem V dan BSD menggunakan kode status keluar yang berbeda. Beberapa implementasi menggunakan status keluar sebagai hitungan jumlah kesalahan yang terjadi; praktik ini tidak bisa dijalankan karena bisa meluap rentang nilai status keluar yang valid. Pengembang standar memilih untuk menutupi ini dengan menetapkan hanya 0 dan> 0 sebagai nilai keluar.

Asumsi 1: aturan untuk menentukan apakah chownberhasil memeriksa pengguna target dan bagian-bagian kelompok secara mandiri, yaitu mereka dari formulir user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Asumsi 2: chown(file, -1, -1)berhasil.

Asumsi 3: aturan untuk menentukan apakah chownberhasil tidak bergantung pada grup mana file saat ini milik.

Konsekuensi: jika chown(file, uid, gid)mau berhasil maka demikian juga chown(file, -1, gid) && chown(file, uid, -1).

Saya tidak tahu varian Unix yang akan melanggar asumsi-asumsi ini, mereka tampaknya cukup aman.

Kalimat ini memiliki tampilan seperti yang dikatakan seseorang dalam komite ketika mereka lelah setelah berjam-jam berdebat berapa banyak pilihan yang bisa diterima di kepala suatu pspanggilan telepon - atau bahwa sekretaris salah menerjemahkan - dan tidak ada yang tertangkap selama peninjauan. Lagi pula, ada alasan lain yang bagus untuk memungkinkan pengguna dan grup diubah secara otomatis, termasuk alasan kinerja yang juga dikutip dalam alasan POSIX, serta atomicity (ah, jika saja ada satu panggilan untuk mengubah kepemilikan dan izin) ).

Kasus di mana asumsi 3 bisa salah ada pada sistem di mana proses bisa mendapatkan kemampuan untuk mengubah pemilik file tetapi hanya jika mereka memiliki izin menulis pada file. Meskipun agak realistis, saya tidak tahu sistem apa pun di mana ini terjadi. Kemudian chgrpke grup dari proses yang berjalan baik sebagai root atau sebagai pengguna yang memiliki file dapat membuat file terlarang untuk nanti chown.

Untuk panggilan rekursif, ada kasus tepi di mana seluruh operan chgrpdiikuti oleh operan keseluruhan chowndapat gagal ketika satu operan berhasil. Ini bukan argumen yang sangat meyakinkan karena melibatkan direktori bahwa pemiliknya tidak memiliki izin untuk melintasi, dan aplikasi yang ingin melindungi terhadap semua kasus seperti itu perlu mengutak-atik izin. Meskipun demikian secara teknis memenuhi kondisi pemikiran ini. Asumsikan bahwa proses yang berjalan memiliki pengguna yang efektif alice, grup yang efektif staff, dan kemampuan untuk mengubah pemilik file secara sewenang-wenang (bukan hanya untuk memberikannya; beberapa varian unix memiliki kemampuan seperti itu, meskipun jarang diberikan pada proses non-root).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied