बिल्ड में जोड़ी गई फाइलसिस्टम ऑब्जेक्ट्स और सेवाओं को अक्सर अलग, विशिष्ट आईडी की आवश्यकता होती है, जिन्हें एंड्रॉइड आईडी (एआईडी) के रूप में जाना जाता है। वर्तमान में, कई संसाधन जैसे फ़ाइलें और सेवाएँ कोर (Android-परिभाषित) AID का अनावश्यक रूप से उपयोग करती हैं; कई मामलों में आप इसके बजाय OEM (OEM-परिभाषित) AID का उपयोग कर सकते हैं।
एंड्रॉइड के पुराने संस्करणों (एंड्रॉइड 7.x और निचले) ने फाइल सिस्टम क्षमताओं और/या कस्टम ओईएम एआईडी को निर्दिष्ट करने के लिए डिवाइस-विशिष्ट android_filesystem_config.h फ़ाइल का उपयोग करके AIDs तंत्र का विस्तार किया। हालाँकि, यह प्रणाली सहज नहीं थी क्योंकि यह OEM AID के लिए अच्छे नामों का उपयोग करने का समर्थन नहीं करती थी, जिसके लिए आपको संख्यात्मक AID के साथ एक दोस्ताना नाम जोड़ने के तरीके के बिना उपयोगकर्ता और समूह फ़ील्ड के लिए कच्चे अंक निर्दिष्ट करने की आवश्यकता होती है।
एंड्रॉइड के नए संस्करण (एंड्रॉइड 8.0 और उच्चतर) फाइल सिस्टम क्षमताओं को विस्तारित करने के लिए एक नई विधि का समर्थन करते हैं। इस नई विधि में निम्नलिखित के लिए समर्थन है:
- कॉन्फ़िगरेशन फ़ाइलों के लिए एकाधिक स्रोत स्थान (एक्सटेंसिबल बिल्ड कॉन्फ़िगरेशन सक्षम करता है)।
- OEM सहायता मूल्यों की बिल्ड-टाइम विवेक जाँच।
- एक कस्टम OEM AID शीर्षलेख का निर्माण जो आवश्यकतानुसार स्रोत फ़ाइलों में उपयोग किया जा सकता है।
- वास्तविक OEM AID मान के साथ एक दोस्ताना नाम का जुड़ाव। उपयोगकर्ता और समूह के लिए गैर-संख्यात्मक स्ट्रिंग तर्कों का समर्थन करता है, अर्थात "2901" के बजाय "फू"।
अतिरिक्त सुधारों में android_ids[] सरणी को system/core/libcutils/include/private/android_filesystem_config.h से हटाना शामिल है। यह सरणी अब बायोनिक में एक पूरी तरह से निजी उत्पन्न सरणी के रूप में मौजूद है, जिसमें getpwnam() और getgrnam() के माध्यम से एक्सेसर्स हैं। (इसमें स्थिर बायनेरिज़ बनाने का साइड इफेक्ट है क्योंकि कोर एड्स संशोधित हैं।) टूलींग और अधिक विवरण के साथ एक रीडमे फ़ाइल के लिए, build/make/tools/fs_config ।
Android आईडी (AID) जोड़ना
एंड्रॉइड 8.0 ने एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) से android_ids[] सरणी को हटा दिया। इसके बजाय सभी AID-अनुकूल नाम system/core/libcutils/include/private/android_filesystem_config.h हेडर फ़ाइल से उत्पन्न होते हैं जब बायोनिक android_ids[] सरणी उत्पन्न करते हैं। AID_* से मेल खाने वाला कोई भी define टूल टूलिंग द्वारा उठाया जाता है और * लोअरकेस नाम बन जाता है।
उदाहरण के लिए, private/android_filesystem_config.h में:
#define AID_SYSTEM 1000
बन जाता है:
- दोस्ताना नाम: सिस्टम
- यूआईडी: 1000
- जीआईडी: 1000
एक नया AOSP कोर AID जोड़ने के लिए, बस android_filesystem_config.h हेडर फ़ाइल में #define जोड़ें। AID बिल्ड पर जनरेट किया जाएगा और उन इंटरफेस को उपलब्ध कराया जाएगा जो उपयोगकर्ता और समूह तर्कों का उपयोग करते हैं। टूलींग पुष्टि करता है कि नया AID एपीपी या ओईएम रेंज के भीतर नहीं है; यह उन श्रेणियों में परिवर्तनों का भी सम्मान करता है और परिवर्तनों या नई ओईएम-आरक्षित श्रेणियों पर स्वचालित रूप से पुन: कॉन्फ़िगर होना चाहिए।
एड्स को कॉन्फ़िगर करना
नए AIDs तंत्र को सक्षम करने के लिए, BoardConfig.mk फ़ाइल में TARGET_FS_CONFIG_GEN सेट करें। यह चर कॉन्फ़िगरेशन फ़ाइलों की एक सूची रखता है, जिससे आप आवश्यकतानुसार फ़ाइलों को जोड़ सकते हैं।
परंपरा के अनुसार, कॉन्फ़िगरेशन फ़ाइलें config.fs नाम का उपयोग करती हैं, लेकिन व्यवहार में आप किसी भी नाम का उपयोग कर सकते हैं। config.fs फ़ाइलें Python ConfigParser ini प्रारूप में हैं और इसमें एक कैप अनुभाग (फ़ाइल सिस्टम क्षमताओं को कॉन्फ़िगर करने के लिए) और एक AIDs अनुभाग (OEM AID को कॉन्फ़िगर करने के लिए) शामिल हैं।
कैप्स अनुभाग को कॉन्फ़िगर करना
कैप्स सेक्शन बिल्ड के भीतर फाइल सिस्टम ऑब्जेक्ट्स पर फाइल सिस्टम क्षमताओं को सेट करने का समर्थन करता है (फाइल सिस्टम को स्वयं भी इस कार्यक्षमता का समर्थन करना चाहिए)।
चूंकि एंड्रॉइड में रूट के रूप में एक स्थिर सेवा चलाने से संगतता परीक्षण सूट (सीटीएस) विफलता का कारण बनता है, प्रक्रिया या सेवा चलाने के दौरान क्षमता बनाए रखने के लिए पिछली आवश्यकताओं में क्षमताओं को स्थापित करना शामिल है, फिर चलाने के लिए उचित एआईडी के लिए setuid / setgid का उपयोग करना। कैप्स के साथ, आप इन आवश्यकताओं को छोड़ सकते हैं और कर्नेल आपके लिए यह कर सकते हैं। जब नियंत्रण main() को सौंप दिया जाता है, तो आपकी प्रक्रिया में पहले से ही वे क्षमताएं होती हैं जिनकी उसे आवश्यकता होती है, इसलिए आपकी सेवा गैर-रूट उपयोगकर्ता और समूह का उपयोग कर सकती है (यह विशेषाधिकार प्राप्त सेवाओं को शुरू करने का पसंदीदा तरीका है)।
कैप्स अनुभाग निम्नलिखित सिंटैक्स का उपयोग करता है:
| अनुभाग | मूल्य | परिभाषा |
|---|---|---|
[path] | फाइलसिस्टम पथ विन्यस्त करने के लिए. / में समाप्त होने वाले पथ को डीआईआर माना जाता है, अन्यथा यह एक फ़ाइल है। अलग-अलग फाइलों में एक ही [path] के साथ कई सेक्शन निर्दिष्ट करना एक त्रुटि है। पायथन संस्करणों में <= 3.2, उसी फ़ाइल में ऐसे अनुभाग हो सकते हैं जो पिछले अनुभाग को ओवरराइड करते हैं; पायथन 3.2 में, यह सख्त मोड पर सेट है। | |
mode | ऑक्टल फ़ाइल मोड | कम से कम 3 अंकों का एक मान्य ऑक्टल फ़ाइल मोड। यदि 3 निर्दिष्ट है, तो यह 0 के साथ उपसर्ग करता है, अन्यथा मोड का उपयोग किया जाता है। |
user | AID_<उपयोगकर्ता> | या तो C मान्य AID के लिए define है या मित्रवत नाम (जैसे AID_RADIO और radio दोनों स्वीकार्य हैं)। कस्टम AID को परिभाषित करने के लिए, AID अनुभाग को कॉन्फ़िगर करना देखें। |
group | AID_<समूह> | उपयोगकर्ता के समान। |
caps | टोपी* | bionic/libc/kernel/uapi/linux/capability.h में प्रमुख CAP_ के बिना घोषित नाम। मिश्रित मामले की अनुमति है। कैप्स कच्चे भी हो सकते हैं:
|
उपयोग के उदाहरण के लिए, फ़ाइल सिस्टम क्षमताओं का उपयोग करना देखें।
सहायता अनुभाग को कॉन्फ़िगर करना
AID अनुभाग में OEM AID शामिल हैं और निम्न सिंटैक्स का उपयोग करता है:
| अनुभाग | मूल्य | परिभाषा |
|---|---|---|
[AID_<name>] | <name> में सेट अपरकेस, संख्या और अंडरस्कोर में वर्ण हो सकते हैं। लोअरकेस संस्करण का उपयोग दोस्ताना नाम के रूप में किया जाता है। कोड समावेशन के लिए जेनरेट की गई हेडर फ़ाइल सटीक AID_<name> का उपयोग करती है।एक ही AID_<name> ( [path] के समान बाधाओं के साथ असंवेदनशील मामला) के साथ कई अनुभागों को निर्दिष्ट करना एक त्रुटि है।<name> को विभाजन नाम से शुरू होना चाहिए ताकि यह सुनिश्चित हो सके कि यह विभिन्न स्रोतों के साथ विरोध नहीं करता है। | |
value | <संख्या> | एक मान्य सी शैली संख्या स्ट्रिंग (हेक्स, ऑक्टल, बाइनरी और दशमलव)। समान मान विकल्प वाले अनेक अनुभागों को निर्दिष्ट करना एक त्रुटि है। मान विकल्प <name> में प्रयुक्त विभाजन के अनुरूप श्रेणी में निर्दिष्ट किया जाना चाहिए। वैध विभाजनों की सूची और उनकी संबंधित श्रेणियों को system/core/libcutils/include/private/android_filesystem_config.h में परिभाषित किया गया है। विकल्प हैं:
|
उपयोग के उदाहरणों के लिए, OEM AID नामों को परिभाषित करना और OEM AID का उपयोग करना देखें।
उपयोग के उदाहरण
निम्नलिखित उदाहरण विस्तार से बताते हैं कि कैसे एक ओईएम एआईडी को परिभाषित और उपयोग किया जाए और फाइल सिस्टम क्षमताओं को कैसे सक्षम किया जाए। OEM AID नाम ( [AID_ name ] ) को विभाजन नाम से शुरू होना चाहिए जैसे " वेंडर_ " यह सुनिश्चित करने के लिए कि वे भविष्य के AOSP नामों या अन्य विभाजनों के साथ विरोध नहीं करते हैं।
OEM सहायता नामों को परिभाषित करना
एक OEM AID को परिभाषित करने के लिए, एक config.fs फ़ाइल बनाएँ और AID मान सेट करें। उदाहरण के लिए, device/x/y/config.fs में, निम्नलिखित सेट करें:
[AID_VENDOR_FOO] value: 2900
फ़ाइल बनाने के बाद, TARGET_FS_CONFIG_GEN चर सेट करें और इसे BoardConfig.mk में इंगित करें। उदाहरण के लिए, device/x/y/BoardConfig.mk में, निम्नलिखित सेट करें:
TARGET_FS_CONFIG_GEN += device/x/y/config.fs
आपका कस्टम AID अब नए बिल्ड पर बड़े पैमाने पर सिस्टम द्वारा उपभोग किया जा सकता है।
OEM एड्स का उपयोग करना
एक OEM AID का उपयोग करने के लिए, अपने C कोड में, अपने संबद्ध Makefile में oemaids_headers शामिल करें, और #include "generated_oem_aid.h" जोड़ें, फिर घोषित पहचानकर्ताओं का उपयोग करना शुरू करें। उदाहरण के लिए, my_file.c में, निम्नलिखित जोड़ें:
#include "generated_oem_aid.h"
…
If (ipc->uid == AID_VENDOR_FOO) {
// Do something
...
अपनी संबद्ध Android.bp फ़ाइल में, निम्नलिखित जोड़ें:
header_libs: ["oemaids_headers"],
यदि आप Android.mk फ़ाइल का उपयोग कर रहे हैं, तो निम्नलिखित जोड़ें:
LOCAL_HEADER_LIBRARIES := oemaids_headers
मित्रवत नामों का उपयोग करना
एंड्रॉइड 9 में, आप किसी भी इंटरफ़ेस के लिए अनुकूल नाम का उपयोग कर सकते हैं जो एआईडी नामों का समर्थन करता है। उदाहरण के लिए:
-
some/init.rcमें एकchownकमांड में:chown vendor_foo /vendor/some/vendor_foo/file
- किसी
serviceमेंsome/init.rc:service vendor_foo /vendor/bin/foo_service user vendor_foo group vendor_foo
क्योंकि दोस्ताना नाम से uid में आंतरिक मैपिंग /vendor/etc/passwd और /vendor/etc/group द्वारा की जाती है, विक्रेता विभाजन को माउंट किया जाना चाहिए।
दोस्ताना नाम जोड़ना
Android 9 में वास्तविक OEM AID मान के साथ एक दोस्ताना नाम जोड़ने के लिए समर्थन शामिल है। आप उपयोगकर्ता और समूह के लिए गैर-संख्यात्मक स्ट्रिंग तर्कों का उपयोग कर सकते हैं, अर्थात "2901" के बजाय " वेंडर_ फू"।
AID से मित्रवत नामों में कनवर्ट करना
OEM AIDs के लिए, Android 8.x को getpwnam और इसी तरह के कार्यों के साथ-साथ उन स्थानों पर, जो getpwnam (जैसे init स्क्रिप्ट) के माध्यम से लुकअप को संभालते हैं, oem_#### के उपयोग की आवश्यकता होती है। एंड्रॉइड 9 में, आप बायोनिक में getpwnam और getgrnam दोस्तों को एंड्रॉइड आईडी (एआईडी) से मैत्रीपूर्ण नामों में परिवर्तित करने के लिए उपयोग कर सकते हैं और इसके विपरीत।
फ़ाइल सिस्टम क्षमताओं का उपयोग करना
फाइल सिस्टम क्षमताओं को सक्षम करने के लिए, config.fs फाइल में एक कैप्स सेक्शन बनाएं। उदाहरण के लिए, device/x/y/config.fs में, निम्न अनुभाग जोड़ें:
[system/bin/foo_service] mode: 0555 user: AID_VENDOR_FOO group: AID_SYSTEM caps: SYS_ADMIN | SYS_NICE
फ़ाइल बनाने के बाद, उस फ़ाइल को BoardConfig.mk में इंगित करने के लिए TARGET_FS_CONFIG_GEN सेट करें। उदाहरण के लिए, device/x/y/BoardConfig.mk में, निम्नलिखित सेट करें:
TARGET_FS_CONFIG_GEN += device/x/y/config.fs
जब सेवा vendor_ foo निष्पादित किया जाता है, तो यह CAP_SYS_ADMIN और CAP_SYS_NICE की क्षमताओं के साथ बिना setuid और setgid कॉल के शुरू होता है। इसके अलावा, vendor_ foo सेवा की SELinux नीति को अब क्षमता setgid setuid आवश्यकता नहीं है और इसे हटाया जा सकता है।
ओवरराइड कॉन्फ़िगर करना (एंड्रॉइड 6.x-7.x)
एंड्रॉइड 6.0 ने fs_config और संबंधित संरचना परिभाषाओं ( system/core/include/private/android_filesystem_config.h ) को system/core/libcutils/fs_config.c में स्थानांतरित कर दिया जहां उन्हें /system/etc/fs_config_dirs और में स्थापित बाइनरी फाइलों द्वारा अद्यतन या ओवरराइड किया जा सकता है। /system/etc/fs_config_files . निर्देशिकाओं और फ़ाइलों के लिए अलग-अलग मिलान और पार्सिंग नियमों का उपयोग करना (जो अतिरिक्त ग्लोब एक्सप्रेशन का उपयोग कर सकते हैं) एंड्रॉइड को दो अलग-अलग तालिकाओं में निर्देशिकाओं और फ़ाइलों को संभालने में सक्षम बनाता है। system/core/libcutils/fs_config.c में संरचना परिभाषाओं ने न केवल निर्देशिकाओं और फाइलों के रनटाइम पढ़ने की अनुमति दी, बल्कि होस्ट फाइल सिस्टम छवियों को ${OUT}/system/etc/fs_config_dirs और ${OUT}/system/etc/fs_config_files के रूप में बनाने के लिए उसी फाइल का उपयोग कर सकता है। ${OUT}/system/etc/fs_config_files .
जबकि फाइल सिस्टम को विस्तारित करने की ओवरराइड विधि को एंड्रॉइड 8.0 में पेश किए गए मॉड्यूलर कॉन्फ़िगरेशन सिस्टम द्वारा हटा दिया गया है, फिर भी आप चाहें तो पुरानी विधि का उपयोग कर सकते हैं। निम्न अनुभागों में बताया गया है कि ओवरराइड फ़ाइलें कैसे उत्पन्न करें और कैसे शामिल करें और फ़ाइल सिस्टम को कॉन्फ़िगर करें।
ओवरराइड फ़ाइलें उत्पन्न करना
आप build/tools/fs_config में fs_config_generate टूल का उपयोग करके संरेखित बाइनरी फ़ाइलें /system/etc/fs_config_dirs और /system/etc/fs_config_files उत्पन्न कर सकते हैं। यह टूल डीएसी आवश्यकताओं को बफर में प्रबंधित करने के लिए एक libcutils लाइब्रेरी फ़ंक्शन ( fs_config_generate() ) का उपयोग करता है और डीएसी नियमों को संस्थागत बनाने के लिए एक फ़ाइल को शामिल करने के लिए नियमों को परिभाषित करता है।
उपयोग करने के लिए, device/ vendor / device /android_filesystem_config.h में एक शामिल फ़ाइल बनाएं जो ओवरराइड के रूप में कार्य करता है। फ़ाइल को निर्देशिका और फ़ाइल प्रतीकों के लिए निम्नलिखित संरचना आरंभीकरण के साथ system/core/include/private/android_filesystem_config.h में परिभाषित structure fs_path_config प्रारूप का उपयोग करना चाहिए:
- निर्देशिकाओं के लिए,
android _device _dirs[]का उपयोग करें। - फ़ाइलों के लिए,
android _device _files[]का उपयोग करें।
android_device_dirs[] और android_device_files[] ] का उपयोग नहीं करते समय, आप NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS और NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_FILES को परिभाषित कर सकते हैं (नीचे उदाहरण देखें)। आप android_filesystem_config.h के लागू बेसनाम के साथ बोर्ड कॉन्फ़िगरेशन में TARGET_ANDROID_FILESYSTEM_CONFIG_H का उपयोग करके ओवरराइड फ़ाइल भी निर्दिष्ट कर सकते हैं।
ओवरराइड फ़ाइलें शामिल हैं
फ़ाइलों को शामिल करने के लिए, सुनिश्चित करें कि PRODUCT_PACKAGES में fs_config_dirs और/या fs_config_files शामिल हैं ताकि यह उन्हें क्रमशः /system/etc/fs_config_dirs और /system/etc/fs_config_files में स्थापित कर सके। बिल्ड सिस्टम कस्टम android_filesystem_config.h को $(TARGET_DEVICE_DIR) में खोजता है, जहां BoardConfig.mk मौजूद है। यदि यह फ़ाइल कहीं और मौजूद है, तो उस स्थान को इंगित करने के लिए बोर्ड कॉन्फ़िगरेशन चर TARGET_ANDROID_FILESYSTEM_CONFIG_H सेट करें।
फाइल सिस्टम को कॉन्फ़िगर करना
एंड्रॉइड 6.0 और उच्चतर में फाइल सिस्टम को कॉन्फ़िगर करने के लिए:
-
$(TARGET_DEVICE_DIR)/android_filesystem_config.hफ़ाइल बनाएँ। - बोर्ड कॉन्फ़िगरेशन फ़ाइल में
fs_config_dirsऔर/याfs_config_filesकोPRODUCT_PACKAGESमें जोड़ें (जैसे,$(TARGET_DEVICE_DIR)/device.mk)।
ओवरराइड उदाहरण
यह उदाहरण device/ vendor / device निर्देशिका में वेक लॉक समर्थन जोड़ने के लिए system/bin/glgps डेमॉन को ओवरराइड करने के लिए एक पैच दिखाता है। निम्नलिखित बातों का ध्यान रखें:
- प्रत्येक संरचना प्रविष्टि मोड, यूआईडी, जीआईडी, क्षमताएं और नाम है।
system/core/include/private/android_filesystem_config.hमेनिफेस्ट #defines (AID_ROOT,AID_SHELL,CAP_BLOCK_SUSPEND) प्रदान करने के लिए स्वचालित रूप से शामिल है। -
android_device_files[]अनुभाग में अनिर्दिष्ट होने परsystem/etc/fs_config_dirsतक पहुंच को दबाने के लिए एक क्रिया शामिल है, जो निर्देशिका ओवरराइड के लिए सामग्री की कमी के लिए एक अतिरिक्त DAC सुरक्षा के रूप में कार्य करता है। हालाँकि, यह कमजोर सुरक्षा है; अगर किसी का नियंत्रण/systemपर है, तो वे आम तौर पर कुछ भी कर सकते हैं जो वे चाहते हैं।
diff --git a/android_filesystem_config.h b/android_filesystem_config.h
new file mode 100644
index 0000000..874195f
--- /dev/null
+++ b/android_filesystem_config.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * permissions and limitations under the License.
+ */
+
+/* This file is used to define the properties of the filesystem
+** images generated by build tools (eg: mkbootfs) and
+** by the device side of adb.
+*/
+
+#define NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+/* static const struct fs_path_config android_device_dirs[] = { }; */
+
+/* Rules for files.
+** These rules are applied based on "first match", so they
+** should start with the most specific path and work their
+** way up to the root. Prefixes ending in * denotes wildcard
+** and will allow partial matches.
+*/
+static const struct fs_path_config android_device_files[] = {
+ { 00755, AID_ROOT, AID_SHELL, (1ULL << CAP_BLOCK_SUSPEND),
"system/bin/glgps" },
+#ifdef NO_ANDROID_FILESYSTEM_CONFIG_DEVICE_DIRS
+ { 00000, AID_ROOT, AID_ROOT, 0, "system/etc/fs_config_dirs" },
+#endif
+};
diff --git a/device.mk b/device.mk
index 0c71d21..235c1a7 100644
--- a/device.mk
+++ b/device.mk
@@ -18,7 +18,8 @@ PRODUCT_PACKAGES := \
libwpa_client \
hostapd \
wpa_supplicant \
- wpa_supplicant.conf
+ wpa_supplicant.conf \
+ fs_config_files
ifeq ($(TARGET_PREBUILT_KERNEL),)
ifeq ($(USE_SVELTE_KERNEL), true)
पिछले रिलीज से फाइल सिस्टम माइग्रेट करना
Android 5.x और इससे पहले के फ़ाइल सिस्टम को माइग्रेट करते समय, ध्यान रखें कि Android 6.x
- कुछ शामिल, संरचनाएँ और इनलाइन परिभाषाएँ निकालता है।
-
system/core/include/private/android_filesystem_config.hसे सीधे चलने के बजायlibcutilsके संदर्भ की आवश्यकता है। डिवाइस निर्माता निजी निष्पादन योग्य जो फ़ाइल या निर्देशिका संरचनाओं के लिएsystem/code/include/private_filesystem_config.hपर निर्भर करते हैं याfs_configकोlibcutilsलाइब्रेरी निर्भरता जोड़ना चाहिए। -
device/ vendor / device /android_filesystem_config.hपर जाने के लिए मौजूदा लक्ष्यों पर अतिरिक्त सामग्री के साथsystem/core/include/private/android_filesystem_config.hकी डिवाइस निर्माता निजी शाखा प्रतियों की आवश्यकता है। - लक्ष्य सिस्टम पर कॉन्फ़िगरेशन फ़ाइलों पर SELinux अनिवार्य एक्सेस कंट्रोल (MAC) लागू करने का अधिकार सुरक्षित रखता है, कार्यान्वयन जिनमें
fs_config()का उपयोग करके कस्टम लक्ष्य निष्पादन योग्य शामिल हैं, उन्हें एक्सेस सुनिश्चित करना चाहिए।