27 मार्च को, हमने मोज़िला में WASI के मानकीकरण की शुरुआत की घोषणा की, WebAssembly सिस्टम इंटरफ़ेस (WebAssembly सिस्टम इंटरफ़ेस)।

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

क्या: WebAssembly एक भौतिक मशीन के बजाय एक वैचारिक के लिए एक कोडांतरक है। यह विभिन्न आर्किटेक्चर पर काम करता है, इसलिए, विभिन्न ऑपरेटिंग सिस्टम पर काम करने के लिए एक वैचारिक ओएस के लिए एक सिस्टम इंटरफ़ेस की आवश्यकता होती है।

यहाँ WASI क्या है: यह WebAssembly प्लेटफ़ॉर्म के लिए एक सिस्टम इंटरफ़ेस है।

हम एक सिस्टम इंटरफ़ेस बनाने का प्रयास करते हैं जो अधिकतम पोर्टेबिलिटी और सुरक्षा के साथ WebAssembly के लिए एक सच्चा साथी बन जाएगा।

कौन: WebAssembly विकास टीम के हिस्से के रूप में, हमने एक उपसमूह का आयोजन किया जो WASI पर मानकीकृत होगा। हम पहले से ही इच्छुक भागीदारों को इकट्ठा कर चुके हैं और नए की तलाश कर रहे हैं।

यहाँ कुछ कारण बताए गए हैं कि हम, हमारे साथी और समर्थक इसे महत्वपूर्ण क्यों मानते हैं:

शॉन व्हाइट, मोज़िला आर एंड डी निर्देशक:

“WebAssembly पहले से ही लोगों के नए प्रकार की आकर्षक सामग्री वितरित करने के तरीके को बदल रहा है। यह सामग्री डेवलपर्स और रचनाकारों की मदद करता है। अब तक, सब कुछ ब्राउज़र के माध्यम से काम किया है, लेकिन WASI के साथ, विभिन्न स्थानों में अधिक उपयोगकर्ताओं और अधिक उपकरणों को WebAssembly से लाभ होगा। ”

टायलर मैकमुलेन, सीटीओ तेजी से:

“हम WebAssembly को एक एज क्लाउड पर जल्दी और सुरक्षित रूप से कोड निष्पादित करने के लिए एक मंच के रूप में देखते हैं। विभिन्न परिवेशों (किनारे और ब्राउज़र) के बावजूद, WASI के लिए धन्यवाद, आपको प्रत्येक प्लेटफ़ॉर्म पर कोड पोर्ट नहीं करना होगा। ”

माइल्स बोरिन्स, नोड संचालन समिति के सीटीओ:

“WebAssembly ने नोड की सबसे बड़ी समस्याओं में से एक को हल कर सकता है: पोर्टेबिलिटी और सुरक्षा बनाए रखते हुए अन्य भाषाओं जैसे सी और सी ++ में लिखे गए पास-देशी गति और पुन: उपयोग कोड को कैसे प्राप्त करें। WASI मानकीकरण इस ओर पहला कदम है। ”

लोरी वॉस, npm के सह-संस्थापक:

“Npm npm पारिस्थितिकी तंत्र की संभावित WebAssembly क्षमताओं के बारे में बेहद उत्साहित है क्योंकि यह सर्वर-साइड जावास्क्रिप्ट अनुप्रयोगों में चलाने के लिए देशी कोड प्राप्त करना बहुत आसान बनाता है। हम इस प्रक्रिया के परिणामों की प्रतीक्षा कर रहे हैं। ”

तो यह एक बड़ी घटना है!

वर्तमान में तीन WASI कार्यान्वयन हैं:

• wasmtime , मोज़िला वेबअवेशन रनटाइम
  
• लुसेट, फास्टली वेबसर्विस रनटाइम
  
• पॉलीफिल ब्राउज़र

कार्रवाई में WASI का प्रदर्शन:


इसके बाद, हम मोज़िला के प्रस्ताव के बारे में बात करेंगे कि यह सिस्टम इंटरफ़ेस कैसे काम करना चाहिए।

सिस्टम इंटरफ़ेस क्या है?

कई लोग कहते हैं कि सी जैसी भाषाएं सिस्टम संसाधनों तक सीधे पहुंच प्रदान करती हैं। लेकिन यह पूरी तरह सच नहीं है। अधिकांश प्रणालियों पर, इन भाषाओं में फ़ाइलों को खोलने या बनाने जैसी चीजों तक सीधी पहुंच नहीं है। क्यों नहीं?

क्योंकि ये सिस्टम संसाधन - फ़ाइलें, मेमोरी और नेटवर्क कनेक्शन - स्थिरता और सुरक्षा के लिए बहुत महत्वपूर्ण हैं।

यदि एक कार्यक्रम गलती से दूसरे के संसाधनों को बर्बाद कर देता है, तो इससे दुर्घटना हो सकती है। इससे भी बदतर, अगर एक कार्यक्रम (या एक उपयोगकर्ता) विशेष रूप से अन्य लोगों के संसाधनों पर हमला करता है, तो यह संवेदनशील डेटा चोरी कर सकता है।



इसलिए, आपको यह नियंत्रित करने का एक तरीका चाहिए कि कौन से प्रोग्राम और उपयोगकर्ता संसाधनों तक पहुंच सकते हैं। लंबे समय तक, सिस्टम डेवलपर्स इस तरह के नियंत्रण प्रदान करने का एक तरीका लेकर आए: सुरक्षा रिंग।

संरक्षण के छल्ले के साथ, ओएस अनिवार्य रूप से सिस्टम संसाधनों के चारों ओर एक सुरक्षात्मक अवरोध स्थापित करता है। यह कोर है। केवल यह एक फ़ाइल बनाने, फ़ाइल खोलने या नेटवर्क कनेक्शन खोलने जैसे ऑपरेशन कर सकता है।

उपयोगकर्ता प्रोग्राम कर्नेल के बाहर चला जाता है जिसे उपयोगकर्ता स्थान कहा जाता है। यदि प्रोग्राम फ़ाइल को खोलना चाहता है, तो उसे कर्नेल के लिए पूछना चाहिए।



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

अधिकांश उपकरणों पर, सिस्टम कॉल्स तक पहुँचने का एकमात्र तरीका सिस्टम कॉल है।



ऑपरेटिंग सिस्टम, सिस्टम कॉल तक पहुँच प्रदान करता है। लेकिन अगर प्रत्येक ओएस की अपनी प्रणाली कॉल है, तो क्या उन्हें कोड के विभिन्न संस्करणों को लिखने की आवश्यकता नहीं है? सौभाग्य से नहीं। अमूर्त का उपयोग करके समस्या को हल किया जाता है।

अधिकांश भाषाओं में एक मानक पुस्तकालय है। कोडिंग करते समय, प्रोग्रामर को यह जानने की आवश्यकता नहीं होती है कि वह किस सिस्टम के लिए लिखता है। यह सिर्फ इंटरफ़ेस का उपयोग करता है। फिर, संकलित करते समय, आपकी उपकरण श्रृंखला चुनती है कि किस सिस्टम के लिए कौन सा इंटरफ़ेस कार्यान्वयन का उपयोग करना है। यह कार्यान्वयन ऑपरेटिंग सिस्टम के एपीआई से कार्यों का उपयोग करता है, इसलिए यह इसके लिए विशिष्ट है।

यह वह जगह है जहाँ सिस्टम इंटरफ़ेस की अवधारणा दिखाई देती है। उदाहरण के लिए, यदि आप विंडोज मशीन के लिए printf को संकलित करते हैं, तो यह विंडोज एपीआई का उपयोग करेगा। यदि मैक या लिनक्स के लिए संकलित किया जाता है, तो यह POSIX का उपयोग करता है।



हालाँकि, यह WebAssembly के लिए एक समस्या है। यहां हम यह नहीं जानते हैं कि संकलन के दौरान भी किस ओएस को प्रोग्राम को ऑप्टिमाइज़ करना है। इस प्रकार, आप WebAssembly पर मानक पुस्तकालय के कार्यान्वयन के अंदर किसी एक ओएस के सिस्टम इंटरफ़ेस का उपयोग नहीं कर सकते।



मैंने पहले ही कहा है कि WebAssembly एक वैचारिक मशीन के लिए एक कोडांतरक है , वास्तविक मशीन नहीं। इसी तरह, WebAssembly को वास्तविक ओएस के बजाय वैचारिक के लिए एक सिस्टम इंटरफ़ेस की आवश्यकता होती है।

लेकिन पहले से ही ऐसे रनटाइम हैं जो इस सिस्टम इंटरफ़ेस के बिना भी ब्राउज़र के बाहर WebAssembly को चला सकते हैं। वे इसे कैसे करते हैं? आइए देखते हैं।

अब WebAssembly ब्राउज़र के बाहर कैसे काम करता है?

WebAssembly कोड जनरेट करने का पहला टूल Emscripten था। यह वेब पर एक विशिष्ट OS सिस्टम इंटरफ़ेस - POSIX का अनुकरण करता है। इसका मतलब यह है कि प्रोग्रामर मानक सी लाइब्रेरी (libc) से कार्यों का उपयोग कर सकता है।

इसके लिए, Emscripten अपने स्वयं के libc कार्यान्वयन का उपयोग करता है। इसे दो भागों में विभाजित किया गया है: पहला एक WebAssembly मॉड्यूल में संकलित किया गया है, और दूसरा जेएस-गोंद कोड में लागू किया गया है। यह जेएस गोंद उस ब्राउज़र को कॉल भेजता है जो ओएस से बात कर रहा है।



अधिकांश शुरुआती WebAssembly कोड को Emscripten के साथ संकलित किया गया है। इसलिए, जब लोग बिना ब्राउज़र के WebAssembly चलाना चाहते थे, तो उन्होंने Emscripten कोड चलाना शुरू कर दिया।

तो इन रनटाइम्स में आपको जेएस-ग्लू कोड में होने वाले सभी कार्यों के लिए अपना कार्यान्वयन करना चाहिए।

लेकिन एक समस्या है। जेएस गोंद कोड द्वारा प्रदान किया गया इंटरफ़ेस मानक या सार्वजनिक इंटरफ़ेस के रूप में डिज़ाइन नहीं किया गया है। उदाहरण के लिए, सामान्य API में read लिए कॉल करने के लिए, JS गोंद कोड _system3(which, varargs) कॉल का उपयोग करता है।



पहला पैरामीटर which एक पूर्णांक है जो हमेशा नाम में संख्या से मेल खाता है (हमारे मामले में 3)।

दूसरा पैरामीटर, varargs तर्कों को सूचीबद्ध करता है। इसे varargs कहा जाता है क्योंकि हमारे पास भिन्न संख्या में तर्क हो सकते हैं। लेकिन WebAssembly एक फ़ंक्शन के लिए चर संख्या के तर्कों को पारित करने की अनुमति नहीं देता है। इसलिए, उन्हें रैखिक स्मृति के माध्यम से प्रेषित किया जाता है, जो रजिस्टरों के माध्यम से असुरक्षित और धीमा है।

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

इसका मतलब है कि वे कोड को फिर से लागू करते हैं (उदाहरण के लिए, तर्कों को हीप मान के रूप में पास करें), जिसने अर्थ दिया कि ईस्मिप्टेन बाधाएं दी गई हैं, लेकिन इन रनटाइम वातावरणों में ऐसी कोई बाधा नहीं है।



अगर हम आने वाले दशकों के लिए WebAssembly पारिस्थितिकी तंत्र का निर्माण कर रहे हैं, तो इसे एक ठोस नींव की जरूरत है, बैसाखी की नहीं। इसका मतलब यह है कि हमारा वास्तविक मानक अनुकरण अनुकरण नहीं हो सकता है।

लेकिन इस मामले में कौन से सिद्धांत लागू होते हैं?

WebAssembly सिस्टम इंटरफ़ेस किन सिद्धांतों का पालन करना चाहिए?

WebAssembly के दो मूलभूत सिद्धांत:

• पोर्टेबिलिटी
  
• सुरक्षा

हम ब्राउज़र से परे जाते हैं, लेकिन इन प्रमुख सिद्धांतों को बनाए रखते हैं।

हालाँकि, POSIX दृष्टिकोण और यूनिक्स एक्सेस कंट्रोल सिस्टम हमें वांछित परिणाम नहीं देता है। आइए देखें कि समस्या क्या है।

पोर्टेबिलिटी

POSIX स्रोत कोड की पोर्टेबिलिटी प्रदान करता है। आप समान स्रोत कोड को विभिन्न कंप्यूटरों के लिए libc के विभिन्न संस्करणों के साथ संकलित कर सकते हैं।



लेकिन WebAssembly को इससे आगे जाना होगा। हमें विभिन्न प्रणालियों के पूरे समूह पर चलने के लिए एक बार संकलन करने की आवश्यकता है। हमें पोर्टेबल बायनेरी चाहिए।



यह कोड वितरण को सरल करता है।

उदाहरण के लिए, यदि WebAssembly में देशी नोड मॉड्यूल लिखे जाते हैं, तो उपयोगकर्ताओं को देशी मॉड्यूल के साथ एप्लिकेशन इंस्टॉल करते समय नोड-जिप चलाने की आवश्यकता नहीं होती है, और डेवलपर्स को दर्जनों बाइनरी फ़ाइलों को कॉन्फ़िगर और वितरित करने की आवश्यकता नहीं होती है।

सुरक्षा

जब कोड ऑपरेटिंग सिस्टम को इनपुट या आउटपुट बनाने के लिए कहता है, तो ओएस को इस ऑपरेशन की सुरक्षा का मूल्यांकन करना चाहिए, आमतौर पर स्वामित्व और समूहों के आधार पर एक्सेस कंट्रोल सिस्टम का उपयोग करना चाहिए।

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

जब कोई उपयोगकर्ता एक कार्यक्रम शुरू करता है, तो उस उपयोगकर्ता की ओर से कार्यक्रम शुरू होता है। यदि उपयोगकर्ता के पास फ़ाइल तक पहुंच है - या तो वह उसका मालिक है, या उस समूह का हिस्सा है जिसकी फ़ाइल तक पहुंच है - फिर प्रोग्राम में समान पहुंच है।



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

सब कुछ बदल गया है। वर्तमान में, सिस्टम आमतौर पर एकल-उपयोगकर्ता हैं, लेकिन अज्ञात विश्वसनीयता के तीसरे पक्ष के कोड का उपयोग करते हैं। अब मुख्य खतरा कोड से आता है जिसे आप स्वयं चलाते हैं।

उदाहरण के लिए, आपके आवेदन में पुस्तकालय के लिए एक नया अनुरक्षक शुरू किया गया है (जैसा कि अक्सर खुले स्रोत में होता है)। वह एक ईमानदार कार्यकर्ता हो सकता है ... या एक घुसपैठिया। और अगर उसके पास आपके सिस्टम तक पहुंच है - उदाहरण के लिए, किसी भी फ़ाइल को खोलने और नेटवर्क पर भेजने की क्षमता - तो यह कोड बहुत नुकसान पहुंचा सकता है।


संदिग्ध आवेदन : मैं उपयोगकर्ता बॉब के लिए काम करता हूं। क्या मैं उसका बिटकॉइन वॉलेट खोल सकता हूं?
कोर : बॉब के लिए? बेशक!
संदेहास्पद ऐप : शानदार! नेटवर्क कनेक्टिविटी के बारे में क्या?

यही कारण है कि तीसरे पक्ष के पुस्तकालयों का उपयोग करना खतरनाक है। WebAssembly सैंडबॉक्स के माध्यम से - एक अलग तरीके से सुरक्षा प्रदान करता है। यहाँ, कोड OS से सीधे बात नहीं कर सकता है। लेकिन फिर सिस्टम संसाधनों तक कैसे पहुंचें? होस्ट (ब्राउज़र या वॉसम रनटाइम) सैंडबॉक्स ऐसे फ़ंक्शंस हैं जिनका कोड उपयोग कर सकता है।

इसका मतलब यह है कि होस्ट प्रोग्राम प्रोग्राम की कार्यक्षमता को सीमित करता है, न कि आपको केवल उपयोगकर्ता की ओर से कार्य करने की अनुमति देता है, जिससे कोई भी सिस्टम पूर्ण उपयोगकर्ता अधिकारों के साथ कॉल करता है।

अपने आप में एक सैंडबॉक्स होने से सिस्टम सुरक्षित नहीं होता है - मेजबान अभी भी सैंडबॉक्स में पूर्ण कार्यक्षमता स्थानांतरित कर सकता है, इस मामले में यह कोई सुरक्षा प्रदान नहीं करता है। लेकिन सैंडबॉक्स मेजबानों के लिए कम से कम एक सैद्धांतिक अवसर प्रदान करता है ताकि अधिक सुरक्षित प्रणाली का निर्माण किया जा सके।


WA : कृपया, यहाँ OS (safe_write, safe_read) के साथ बातचीत करने के लिए कुछ सुरक्षित खिलौने हैं।
संदेहास्पद अनुप्रयोग : अरे अरे ... नेटवर्क तक मेरी पहुंच कहां है?

किसी भी सिस्टम इंटरफ़ेस में, आपको इन दो सिद्धांतों का पालन करना होगा। पोर्टेबिलिटी सॉफ्टवेयर विकास और वितरण को आसान बनाता है, और होस्ट और उपयोगकर्ताओं की सुरक्षा के लिए उपकरण बिल्कुल आवश्यक हैं।

ऐसे सिस्टम इंटरफ़ेस को क्या देखना चाहिए?

इन दो प्रमुख सिद्धांतों को देखते हुए, WebAssembly सिस्टम इंटरफ़ेस क्या होना चाहिए?

यह हम मानकीकरण प्रक्रिया में पता लगाएंगे। हालाँकि, हमारे पास शुरुआत के लिए एक सुझाव है:

• मानक इंटरफेस का एक मॉड्यूलर सेट बनाना
  
• आइए वसी-कोर कोर मॉड्यूल के मानकीकरण से शुरू करें।

वासी-कोर में क्या होगा? ये सभी कार्यक्रमों द्वारा आवश्यक मूल बातें हैं। मॉड्यूल फाइल, नेटवर्क कनेक्शन, घड़ियां और यादृच्छिक संख्याओं सहित अधिकांश POSIX कार्यक्षमता को कवर करेगा।

बुनियादी कार्यक्षमता में से बहुत कुछ इसी तरह के दृष्टिकोण की आवश्यकता होगी। उदाहरण के लिए, एक POSIX फ़ाइल-उन्मुख दृष्टिकोण खुले, बंद, पढ़ा और सिस्टम कॉल के साथ प्रदान किया जाता है, और बाकी सब कुछ ऊपर से ऐड-ऑन है।

लेकिन wasi-core सभी POSIX कार्यक्षमता को कवर नहीं करता है। उदाहरण के लिए, एक प्रक्रिया की अवधारणा स्पष्ट रूप से WebAssembly में फिट नहीं होती है। इसके अलावा, यह स्पष्ट है कि प्रत्येक WebAssembly इंजन को fork जैसे प्रक्रिया संचालन का समर्थन करना चाहिए। लेकिन हम fork मानकीकरण भी संभव बनाना चाहते हैं।



Rust जैसी भाषाएं अपने मानक पुस्तकालयों में सीधे wasi-core का उपयोग करेंगी। उदाहरण के लिए, ustw_path_open को कॉल करके WebAssembly में संकलन करते समय रस्ट से open लागू किया जाता है।

C और C ++ के लिए, हमने wasi-sysroot बनाया, जो wasi-core कार्यों के संदर्भ में libc को कार्यान्वित करता है।



हम उम्मीद करते हैं कि क्लैंग जैसे कंपाइलर WASI API के साथ बातचीत करने में सक्षम होंगे, और Rust कंपाइलर और Emscripten जैसी पूरी टूल चेन WASI को अपने सिस्टम के कार्यान्वयन के हिस्से के रूप में उपयोग करेंगे।

कस्टम कोड इन WASI कार्यों को कैसे लागू करता है?

रनटाइम जिसमें कोड निष्पादित होता है, वह वस्तु को सैंडबॉक्स में रखते हुए, वासी-कोर फ़ंक्शन को पास करता है।



यह पोर्टेबिलिटी प्रदान करता है, क्योंकि प्रत्येक होस्ट का अपना प्लेटफ़ॉर्म विशेष रूप से अपने प्लेटफ़ॉर्म के लिए हो सकता है: WebAssembly runtimes जैसे Mozilla Wasmtime और Fastly Lucet, से Node या यहां तक ​​कि ब्राउज़र तक।

यह विश्वसनीय अलगाव भी प्रदान करता है, क्योंकि मेजबान एक सॉफ्टवेयर के आधार पर चयन करता है, जो कि सैंडबॉक्स में ट्रांसफर करने के लिए wasi-core फ़ंक्शंस है, जो कि सिस्टम को कॉल करना चाहिए। यह सुरक्षा है।



WASI प्रणाली में एक प्राधिकरण-आधारित सुरक्षा अवधारणा शुरू करके सुरक्षा बढ़ाता है और बढ़ाता है।

आमतौर पर, यदि कोड को फ़ाइल खोलने की आवश्यकता होती है, तो यह लाइन में पथ नाम के साथ open कॉल करता है। फिर, ओएस यह जांचता है कि क्या कोड को ऐसी कार्रवाई का अधिकार है (प्रोग्राम लॉन्च करने वाले उपयोगकर्ता के अधिकारों के आधार पर)।

WASI के मामले में, किसी फ़ाइल को एक्सेस करने के लिए किसी फ़ंक्शन को कॉल करते समय, आपको एक फ़ाइल डिस्क्रिप्टर पास करना होगा जिसमें फ़ाइल के लिए या फ़ाइल वाली निर्देशिका के लिए अनुमतियाँ संलग्न हैं।

इस प्रकार, आपके पास कोड नहीं हो सकता है जो गलती से आपको खोलने के लिए कहता है /etc/passwd । इसके बजाय, कोड केवल अपनी निर्देशिकाओं के साथ काम कर सकता है।



यह विभिन्न सिस्टम कॉल को पृथक कोड में सुरक्षित रूप से हल करने की अनुमति देता है क्योंकि इन सिस्टम कॉल की क्षमताएं सीमित हैं।

और इसलिए प्रत्येक मॉड्यूल में। डिफ़ॉल्ट रूप से, मॉड्यूल में फ़ाइल विवरणकों तक पहुंच नहीं है। लेकिन अगर एक मॉड्यूल के कोड में एक फाइल डिस्क्रिप्टर होता है, तो वह इसे अन्य मॉड्यूल में कहे गए फंक्शन्स में पास कर सकता है। या अन्य कार्यों को पारित करने के लिए फ़ाइल डिस्क्रिप्टर के अधिक सीमित संस्करण बनाएं।

इस प्रकार, रनटाइम फ़ाइल डिस्क्रिप्टर को पास करता है जो एप्लिकेशन शीर्ष-स्तरीय कोड में उपयोग कर सकता है, और फिर फाइल डिस्क्रिप्टर को आवश्यकतानुसार पूरे सिस्टम में वितरित किया जाता है।



यह WebAssembly को कम से कम विशेषाधिकार के सिद्धांत के करीब लाता है, जहां मॉड्यूल को केवल अपना काम करने के लिए आवश्यक संसाधनों के न्यूनतम सेट तक पहुंच मिलती है।

यह अवधारणा विशेषाधिकार आधारित सुरक्षा पर आधारित है, जैसा कि CloudABI और कैप्सिकम में है। इन प्रणालियों में से एक समस्या कोड की कठिन पोर्टेबिलिटी है। लेकिन हम मानते हैं कि इस समस्या को हल किया जा सकता है।

यदि कोड पहले से ही सापेक्ष फ़ाइल पथों के साथ openat का उपयोग करता है, तो कोड को संकलित करना बस काम करेगा।

यदि कोड open और ओपटैट-स्टाइल का उपयोग करता है तो बहुत अधिक कठोर है, WASI एक वृद्धिशील समाधान प्रदान करेगा। Libpreopen का उपयोग करते हुए, आप फ़ाइल पथों की एक सूची बनाते हैं , जिसके लिए एप्लिकेशन की कानूनी पहुंच होती है। फिर open उपयोग करें, लेकिन केवल इन रास्तों के साथ।

आगे क्या है?

हमारा मानना ​​है कि wasi-core एक अच्छी शुरुआत है। यह WebAssembly की पोर्टेबिलिटी और सुरक्षा को बरकरार रखता है, जो पारिस्थितिकी तंत्र के लिए एक ठोस आधार प्रदान करता है।

लेकिन वासी-कोर के पूर्ण मानकीकरण के बाद, अन्य मुद्दों को हल करने की आवश्यकता है, जिनमें शामिल हैं:

• अतुल्यकालिक इनपुट-आउटपुट
  
• फ़ाइल निगरानी
  
• फ़ाइल लॉक

यह केवल शुरुआत है, इसलिए यदि आपके पास कोई विचार है, तो शामिल हों !