Opsi ICACLS: Mengapa / t diperlukan dengan (OI) (OC)?


3

Jika saya menggunakan ICACLS.exe untuk mengatur izin pada folder dengan perintah seperti

icacls "C:\Some\Directory" /grant "somedomain\someUser:(OI)(CI)F" /t

mengapa opsi / t diperlukan? Bukankah itu kasus (OI) (CI) akan menyebabkan izin untuk diwarisi ke semua objek di dalam C:\Some\Directory pohon?

Untuk sedikit lebih spesifik, anggaplah dalam contoh saya di atas saya memiliki direktori C:\Some\Directory\Tree. Misalkan direktori ini memiliki tidak izin eksplisit ditentukan. Menambahkan izin eksplisit "somedomain \ someUser: (OI) (CI) F" ke direktori itu tidak akan menghasilkan apa-apa, karena sudah diwarisi. Apakah icacl bahkan melakukan ini? (Sunting: ya, jika Anda menunggu cukup lama!) Jadi jika saya tahu pohon direktori tidak memiliki izin eksplisit, saya benar-benar tidak memerlukan opsi / t (yang menghabiskan banyak waktu pada pohon direktori 8TB dengan ratusan jutaan file ...)

Jawaban:


2

Bukankah itu kasus (OI) (CI) akan menyebabkan izin untuk diwarisi?

Ini dijelaskan oleh deskripsi untuk /t:

Lintasi semua subfolder untuk mencocokkan file / direktori. Ini akan menerapkan perubahan izin untuk semua subfolder apakah mereka diatur untuk mewarisi izin dari orang tua .

Sumber icacl


Itu tidak benar-benar menjawab pertanyaan saya. Dikatakan: jika warisan tidak disetel, itu akan menyalin izin ke semua sub folder (yang jelas mencapai sesuatu yang signifikan); dan jika pewarisan diatur, itu juga akan menyalin izin, tetapi tidak mengatakan mengapa ini diperlukan! Jika warisan berarti, yah, berarti warisan, maka saya tidak mengerti mengapa itu perlu. Fakta bahwa mereka menyatakan "apakah mereka akan mewarisi izin atau tidak" mengatakan bahwa memang ada pertanyaan di sini untuk dijawab.
David I. McIntosh

@ DavidI.McIntosh Ada berbagai jenis warisan. (OI)(CI)/t akan mengatur warisan menjadi (OI)(CI) jika tidak disetel sama sekali, setel ke (IO) atau kombinasi selain (OI)(CI)
DavidPostill

David - Apakah Anda belum memiliki 1.000.000 rep pada SU belum? Sebelum Anda menyadarinya, Anda akan lebih tinggi daripada MC "The Mac Daddy" MC !!
Pimp Juice IT

@DavidPostill: komentar kedua Anda masih belum jelas - pasti ada sesuatu yang mendasar yang saya tidak mengerti? Saya mengedit pertanyaan saya menjadi sedikit lebih spesifik. Mungkin Anda bisa melihat lagi? Terima kasih.
David I. McIntosh

0

Beberapa percobaan pada pohon direktori sepele menunjukkan bahwa:

1) The (OI) (CI) memang menyebabkan izin untuk diwarisi - seperti ACE yang diwariskan dalam DACL tentu saja, bukan ACE eksplisit - untuk semua sub-objek (mengingat bahwa warisan belum dinonaktifkan pada sub-objek) , seperti yang diharapkan.

2) Opsi / t menyebabkan icacls untuk melintasi pohon dan menambahkan izin yang sama persis untuk masing-masing sub-direktori sebagai eksplisit izin.

Hasilnya adalah bahwa jika seseorang melihat izin keamanan pada sub-direktori, Anda akan melihat dua identik entri, satu menjadi izin yang diwarisi, dan satu menjadi pengaturan izin eksplisit direktori (kecuali jika warisan dinonaktifkan pada subdirektori atau direktori intervensi lainnya).

Apakah seseorang menginginkan ini atau tidak adalah pertanyaan lain, tetapi kemungkinan besar tidak. Memiliki izin yang ditentukan dua kali tidak terlalu berguna, kecuali jika ada beberapa perubahan di masa depan yang perlu Anda waspadai.

Pada sistem file besar, ini bisa memakan waktu loooooooong untuk menyelesaikannya.

Fakta bahwa dokumentasi menyatakan "apakah mereka diatur untuk mewarisi izin" mungkin adalah untuk mengingatkan Anda untuk:

1) menyalin sebagai izin eksplisit ke semua sub direktori mungkin tidak diperlukan jika izin mengandung (OI)(CI)

tapi

2) jika subdirektori diatur untuk tidak mewarisi izin, ini sebenarnya mencapai sesuatu yang signifikan: pada direktori seperti itu, izin tidak akan diwarisi dari induknya (mis. The (OI)(CI) warisan ditekan), tetapi masih ada karena ditambahkan sebagai izin eksplisit.

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.