ICACLS विकल्प: (OI) (OC) के साथ / t की आवश्यकता क्यों है?

Question

अगर मैं ICACLS.exe का उपयोग किसी आदेश जैसे फ़ोल्डर पर अनुमतियों को सेट करने के लिए करता हूं

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

/ t विकल्प क्यों आवश्यक है? क्या ऐसा नहीं है कि (OI) (CI) अनुमतियों के कारण सभी वस्तुओं को विरासत में मिला होगा C:\Some\Directory पेड़?

थोड़ा और विशिष्ट होने के लिए, मेरे उदाहरण में मान लीजिए कि मेरे पास एक निर्देशिका है C:\Some\Directory\Tree। मान लीजिए कि यह निर्देशिका है नहीं स्पष्ट अनुमतियाँ परिभाषित। स्पष्ट निर्देशिका "somedomain \ someUser: (OI) (CI) F" को उस निर्देशिका में जोड़ने से कुछ भी हासिल नहीं होगा, क्योंकि यह पहले से ही विरासत में मिला है। क्या icacls भी ऐसा करता है? (संपादित करें: हाँ, यदि आप काफी समय तक प्रतीक्षा करते हैं!) तो अगर मुझे पता है कि एक निर्देशिका वृक्ष की कोई स्पष्ट अनुमति नहीं है, तो मुझे वास्तव में / t विकल्प की आवश्यकता नहीं है (जो कि 8TB निर्देशिका के पेड़ पर सैकड़ों की संख्या में एक जबरदस्त समय बर्बाद करता है लाखों फाइलें ...)

Answer 1

क्या ऐसा नहीं है कि (OI) (CI) इनहेरिट की गई अनुमतियों का कारण होगा?

नहीं, इसके लिए विवरण द्वारा समझाया गया है /t:

फ़ाइलों / निर्देशिकाओं से मिलान करने के लिए सभी सबफ़ोल्डरों को पार करें। यह सभी सबफ़ोल्डर्स के लिए अनुमति परिवर्तन लागू करेगा माता-पिता से अनुमति प्राप्त करने के लिए वे सेट हैं या नहीं ।

स्रोत icacls

Comments

यह वास्तव में मेरे सवाल का जवाब नहीं है। यह कहता है: यदि वंशानुक्रम निर्धारित नहीं किया गया है, तो यह सभी उप फ़ोल्डरों की अनुमतियों को कॉपी करेगा (जो स्पष्ट रूप से कुछ महत्वपूर्ण को पूरा करता है); और यदि वंशानुक्रम निर्धारित है, तो यह अनुमतियों की प्रतिलिपि भी बना देगा, लेकिन यह नहीं कहता कि यह क्यों आवश्यक है! अगर विरासत का मतलब है, ठीक है, विरासत का मतलब है, तो मैं नहीं देखता कि यह क्यों जरूरी है। मात्र तथ्य यह है कि वे कहते हैं कि "वे अनुमति देने के लिए निर्धारित हैं या नहीं" कहते हैं कि वास्तव में यहाँ एक सवाल का जवाब दिया जाना है।

— David I. McIntosh

@ DavidI.McIntosh विरासत के विभिन्न प्रकार हैं। (OI)(CI)/t के लिए उत्तराधिकार निर्धारित करेगा (OI)(CI) यदि यह बिल्कुल सेट नहीं है, तो सेट करें (IO) या कुछ अन्य संयोजन की तुलना में (OI)(CI)

— DavidPostill

डेविड - क्या आपके पास अभी तक SU पर 1,000,000 प्रतिनिधि नहीं है? इससे पहले कि आप यह जानते हैं, आप हैरी "द मैक डैडी" एमसी से अधिक होंगे !!

— Pimp Juice IT

@DavidPostill: आपकी दूसरी टिप्पणी अभी भी मुझे सीधे सेट नहीं करती है - कुछ मौलिक होना चाहिए जो मुझे समझ में नहीं आता है? मैंने अपने प्रश्न को थोड़ा और विशिष्ट होने के लिए संपादित किया। शायद आपका एक और रूप हो सकता है? धन्यवाद।

— David I. McIntosh

Answer 2

एक तुच्छ निर्देशिका पेड़ पर कुछ प्रयोग से पता चलता है कि:

1) (OI) (CI) वास्तव में इनहेरिट की जाने वाली अनुमतियों का कारण बनता है - जैसा कि ACE के उत्तराधिकार में विरासत में मिला है, स्पष्ट ACE को - सभी उप-वस्तुओं को नहीं दिया गया (यह देखते हुए कि विरासत उप-ऑब्जेक्ट पर अक्षम नहीं हुई है) , जैसा कि कोई उम्मीद करेगा।

2) / t विकल्प आइकनों को पेड़ को पीछे हटाने और प्रत्येक के लिए सटीक समान अनुमति जोड़ने का कारण बनता है उप-निर्देशिका एक के रूप में मुखर अनुमति।

परिणाम यह है कि यदि कोई उप-निर्देशिका पर सुरक्षा अनुमतियों को देखता है, तो आप देखेंगे दो समान प्रविष्टियाँ, एक विरासत में मिली अनुमति, और एक होने के नाते निर्देशिका स्पष्ट अनुमति सेटिंग (जब तक कि उपनिर्देशिका या कुछ अन्य हस्तक्षेप निर्देशिका पर विरासत को अक्षम नहीं किया गया था)।

कोई यह चाहता है या नहीं यह एक और सवाल है, लेकिन संभावना नहीं है। दो बार निर्दिष्ट अनुमति प्राप्त करना विशेष रूप से उपयोगी नहीं है, जब तक कि भविष्य में होने वाले कुछ बदलावों से आपको बचना चाहिए।

बड़े पैमाने पर फ़ाइल सिस्टम पर, यह पूरा करने के लिए एक loooooooong समय ले सकता है।

तथ्य यह है कि प्रलेखन में कहा गया है कि "वे अनुमति देने के लिए निर्धारित हैं या नहीं" शायद आपको सचेत करना है:

1) सभी उप निर्देशिकाओं के लिए स्पष्ट अनुमतियों के रूप में नकल करना आवश्यक नहीं है यदि अनुमति हो (OI)(CI)

परंतु

2) यदि कोई उपनिर्देशिका इनहेरिट करने की अनुमति नहीं देने के लिए सेट है, तो यह वास्तव में कुछ महत्वपूर्ण को पूरा करता है: ऐसी निर्देशिका पर, अनुमति माता-पिता से विरासत में नहीं ली जाएगी (अर्थात अंतर्निहित (OI)(CI) विरासत को दबा दिया जाता है), लेकिन यह अभी भी एक स्पष्ट अनुमति के रूप में जोड़े जाने के गुण से होगा।