मैं फिर भी जिज्ञासा कर रहा हूं अगर जावा पैकेजों और कक्षाओं के श्वेतसूची (हालांकि छोटे) पर आम तौर पर सहमति होती है जिसे उपयोगकर्ता के लिए महत्वपूर्ण जोखिम के बिना पहुंचा जा सकता है।
हां वहाँ सफेद सूचियां हैं, लेकिन मुझे नहीं पता कि वे "आम तौर पर सहमत" कैसे हैं। सामुदायिक सर्वसम्मति एक श्वेत सूची में प्रवेश करने का एक तरीका है, लेकिन आप सूची निर्माताओं के अनुभव को भी देख सकते हैं, और देख सकते हैं कि उनकी प्रक्रिया समझ में आता है या नहीं।
जो ई परियोजना एक जावा के "taming" के साथ आया था, और कहा कि के कुछ हिस्सों में से एक वर्ग/विधि/क्षेत्र द्वारा मुख्य लाइब्रेरीज की एक सफेद सूची थी। उदाहरण के लिए, StringBuilder के लिए, StringBuilder.safej कहते
# Manually verified.
class("java.lang.StringBuilder",
static(constructor("StringBuilder()"),
constructor("StringBuilder(CharSequence)"),
...
method(suppress, "insert(int, Object)", comment("calls toString on arbitrary object")),
जबकि Runtime.safej कहते
# auto-generated safej: default deny everything
class("java.lang.Runtime",
static(method(suppress, "getRuntime()", comment("default deny")),
method(suppress, "runFinalizersOnExit(boolean)", comment("default deny"))),
...
taming समझने के लिए, Joe-E paper जो कहते देखें:
4.2.1 जावा Taming कक्षा पुस्तकालय
जावा लाइब्रेरी में कई स्थिर विधियां हैं जिनके पास बाहरी दुनिया पर प्रभाव हैं, साथ ही कई रचनाकार जो समान प्रभावों को अनुमति देने वाली ऑब्जेक्ट्स बनाते हैं। यह जावा में परिवेश प्राधिकरण का एक प्रमुख स्रोत है। उदाहरण के लिए, फ़ाइल में एक कन्स्ट्रक्टर है जो एक स्ट्रिंग लेगा और उस ऑब्जेक्ट को उस नाम के साथ फाई का प्रतिनिधित्व करेगा। परिणामी ऑब्जेक्ट नामित फाई को पढ़ने, लिखने या हटाने के लिए उपयोग किया जा सकता है। जावा सुरक्षा प्रबंधक या ऑपरेटिंग सिस्टम द्वारा स्पष्ट स्पष्ट नियंत्रण नियंत्रण, यह किसी भी जावा कोड को फाईस सिस्टम पर पूर्ण नियंत्रण की अनुमति देता है। जो-ई में, हम यह सुनिश्चित करना चाहते हैं कि कोड केवल तभी ली जा सकता है यदि फाई (या एक सुपरडायरेक्टरी) की क्षमता उस कोड के गतिशील दायरे में है।
नतीजतन, हमें जो-ई के वैश्विक दायरे में उपर्युक्त फ़ाइल कन्स्ट्रक्टर की अनुमति नहीं देनी चाहिए। हम जावा पुस्तकालयों का एक सबसेट है जिसमें केवल शामिल हैं जो उन रचनाकारों, विधियों और फाइल्स हैं जो संगत हैं, इस सिद्धांत के साथ कि सभी विशेषाधिकार क्षमता के माध्यम से दिए जाने चाहिए। हम इस गतिविधि को कॉलिंग कहते हैं, क्योंकि यह अनियमित क्लास लाइब्रेरी को एक क्षमता-सुरक्षित सबसेट में बदल देता है। जोएई वाई-फाई जो-ई प्रोग्रामों को इस श्रेणी के सबसेट में केवल कक्षाओं, कन्स्ट्रक्टर, विधियों और फाइल्स का उल्लेख करने की अनुमति देता है। यदि स्रोत कोड इस सबसेट के बाहर कुछ भी बताता है, जो-ई veri fi er fls यह एक त्रुटि के रूप में है।
टमिंग परिवेश प्राधिकरण को खत्म करने में मदद करता है, क्योंकि यह लाइब्रेरी विधियों को सुनिश्चित करता है जो परिवेश प्राधिकरण प्रदान करते हैं जो-ई कार्यक्रमों तक पहुंच योग्य नहीं हैं। हम का खुलासा करने के लिए टमिंग का भी उपयोग करते हैं, केवल जावा लाइब्रेरी का सबसेट जो क्षमता अनुशासन प्रदान करता है।
क्या यह कोड किसी (उदा। आपका) सर्वर पर या क्लाइंट मशीनों पर चल रहा है? –
बिल्कुल वही नहीं है, लेकिन यह प्रश्न आपके लिए उपयोगी साबित हो सकता है यदि आपने इसे पहले ही नहीं खोजा है: http://stackoverflow.com/questions/6210045/bullet-proof-groovy-script-embedding –
@AndrewThompson कोड होगा क्लाइंट मशीनों पर चलाएं, हालांकि चिंता यह है कि मैं अंततः मल्टीप्लेयर समर्थन और संशोधित सर्वर होस्ट करने की क्षमता जोड़ना चाहता हूं। इस उदाहरण में, मैं ऐसे (तृतीय पक्ष) संशोधित सर्वरों को सीधे कनेक्ट करने के लिए आवश्यक मॉड फ़ाइलों (जिसमें स्क्रिप्ट शामिल हो) प्रदान करने की अनुमति देने की व्यवहार्यता को देख रहा हूं। यह निश्चित रूप से "ऑप्ट-इन" प्रक्रिया होने की आवश्यकता होगी, लेकिन इससे सुरक्षा चिंता कम नहीं होती है। [यहां] देखें (http://gamedev.stackexchange.com/questions/59390/how-far-should-i-go-in-securing-groovy-mod-scripts) – Hawkwing