कोड एक्सेस सुरक्षा एक मजाक है?

Question

मैंने कोड एक्सेस सुरक्षा के बारे में इस article के बारे में अभी पढ़ा है। यह उस में इस तरह के एक उदाहरण है:

using System.Security.Permissions; 
public class MyFileAccessor 
{ 
    public MyFileAccessor(String path, bool readOnly) 
    { 
    path = MakeFullPath(path); // helper fcn 
    FileIOPermissionAccess desiredAccess = readOnly 
     ? FileIOPermissionAccess.Read 
     : FileIOPermissionAccess.AllAccess; 
    FileIOPermission p = new FileIOPermission(desiredAccess, path); 
    p.Demand(); 
    // 
    ••• 
    open the file 
    } 
    // ••• 
} 

क्या होगा यदि मैं FileIOPermissionAccess प्रकार का उपयोग नहीं किया और p.Demand() मेरी कोड में बिल्कुल भी तरह कोड समेत कभी नहीं? दूसरे शब्दों में, अगर मैं कुछ बुरा करना चाहता हूं, तो मुझे इसके लिए अनुमति मांगने के लिए परेशान क्यों होना चाहिए? क्या यह एक मजाक नहीं है? या मैंने इसे गलत लिया? (FileStream का उपयोग कर उदाहरण के लिए)

Answer 1

ठीक है, हाँ, उदाहरण एक मजाक का थोड़ा सा है, आप कभी ऐसा कुछ नहीं लिखेंगे। क्या गुम है वास्तव में महत्वपूर्ण हिस्सा है, कोड जो फ़ाइल खोलता है। इसका एक यथार्थवादी संस्करण, कहना होगा, CreateFile() को पिनवोक करें।

बिंदु यह है कि विंडोज सीएएस के बारे में कुछ नहीं जानता है।इसलिए यदि आप इस तरह एक उपयोगिता कार्य प्रदान करते हैं और आप सीएएस नियमों को लागू करना चाहते हैं तो आपको यह सत्यापित करना होगा कि आपका कॉलिंग कोड आवश्यक अनुमति है। बेशक, इस तरह का कोड वास्तव में केवल .NET ढांचे में आता है। FileStream.Init() पर एक नज़र डालें और CreateFile कॉल से पहले फ़ाइल IOPermission की मांग की जा रही है।

Answer 2

फ़ाइल पहुँच स्वचालित रूप से FileIOPermission की मांग करेंगे। और यह सभी मानक वर्गों के लिए है, जब वे कुछ कार्रवाई करते हैं जिसके लिए अनुमति की आवश्यकता होती है तो वे इसे स्वचालित रूप से मांगेंगे। .NET Framework Security here के अंतर्गत देखें। तो नमूना कोड बेकार है, कोई भी स्पष्ट रूप से फ़ाइल अनुमतियों की मांग नहीं करेगा। यह उचित है यदि आप कुछ एपीआई विकसित करते हैं और आपका कोड हस्ताक्षरित है ताकि कोई भी इसे बदल सके।

अब असली दुनिया में, आप फ़ाइलों को एक्सेस करने MyFileAccessor तरह कक्षाएं लिख नहीं होगा:

आगे पढ़ें, यहाँ उस लेख से उद्धरण है। इसके बजाए, आप System.IO.FileStream जैसे सिस्टम-प्रदत्त वर्गों का उपयोग करेंगे, जिन्हें पहले से ही आपके लिए उपयुक्त सुरक्षा जांच करने के लिए डिज़ाइन किया गया है। वे अक्सर कन्स्ट्रक्टर में किए गए सभी प्रदर्शन और सुरक्षा प्रभावों के साथ किए जाते हैं जिन पर मैंने पहले चर्चा की थी।

Answer 3

java.io एपीआई के अंदर

, आप अपने आप को आश्वस्त कर सकते हैं कि चेक किए जा रहे हैं। यदि आप पहुंच को नियंत्रित करना चाहते हैं (ऐसा होने से पहले एक क्रैश को छोड़कर) आपको एपीआई कॉल द्वारा किए गए आंतरिक चेक में उचित चेक प्राइवेट करना होगा।

जावा कोड अक्सर आपके द्वारा नियंत्रित कंप्यूटर पर चलता है, लेकिन यह अक्सर उन कंप्यूटरों पर चलता है जिन्हें आप नियंत्रित नहीं करते हैं। जावा एप्लेट्स के बारे में सोचो। उन्हें फ़ाइल सिस्टम तक पहुंचने की अनुमति मांगी जानी चाहिए क्योंकि कार्यक्रम के लेखक को हर किसी के फाइल सिस्टम में अनचेक पहुंच की अनुमति नहीं दी जानी चाहिए।

आप कुछ दुर्भावनापूर्ण करने से लोगों में से एक समूह को रोकने के लिए की जरूरत है, तो आप संभवतः कुछ सुरक्षा के लिए दुर्भावनापूर्ण कर असली होने के लिए हर किसी से रोकने के लिए की जरूरत है। अन्यथा, बीमार कर्ता सिर्फ यह कहेंगे कि वे भरोसेमंद अनचेक समूह का हिस्सा हैं।

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

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