Android system attribute dynamic isolation and access control method

Abstract

The application discloses an Android system attribute dynamic isolation and access control method and relates to the field of operating system security control. A bottom-layer runtime library identifies the reliability of an application based on a user identifier and a process memory mapping record; for an untrusted application, system attribute shared memory maintained by a background daemon is read through memory mapping, and a lock-free order lock is combined to guarantee reading consistency, and a replacement attribute is returned according to a self-defined configuration. In a strict mode, the real result of an unconfigured attribute is shielded; for a system attribute traversal request, a proxy callback, attribute filtering and native attribute pointer replacement are used to realize traversal view isolation. The background daemon receives dynamic configuration instructions through a Unix domain socket and updates the shared memory through an atomic operation. The method further provides a privilege bypass mechanism, realizes high performance, low delay and fine-grained system attribute dynamic isolation and access control.

Description

Technical Field

[0001] This invention relates to the field of operating system security control, and specifically to a method for implementing dynamic attribute isolation and access control on an Android system. Background Technology

[0002] With the rapid development of the mobile internet, the Android operating system has become the world's leading mobile operating system platform. In the Android system, System Properties, as the core configuration management mechanism, stores critical data such as device hardware information, system version, and build parameters. These properties typically exist in key-value pairs and are accessible to applications through a unified interface. However, with increasingly stringent privacy protection requirements and ever-growing demands for application security control, the existing system property access mechanism has revealed numerous shortcomings in terms of fine-grained control and dynamic isolation.

[0003] Existing technologies offer several solutions for system access control, process isolation, and low-level attribute simulation. Chinese patent CN111125793B discloses a method for trusted verification of object memory; international patent WO2022170946A1 describes a control method for intercepting access requests from untrusted applications by isolating processes. Furthermore, regarding desktop simulation of the Android environment, Chinese patent CN108762815B discloses a method for implementing an Android runtime environment based on a non-virtualized architecture. This method reconstructs the basic C library (xBionic) and simulates the Android system attribute key-value pair space in a memory region within the Linux system. However, this solution aims to address low-level compatibility across platform runtime environments and cannot achieve dynamic, fine-grained customization and isolation of read-only system attributes such as ro. for specific applications (especially untrusted user applications). It also cannot effectively hide or replace real system fingerprint data in scenarios such as privacy compliance detection. While these existing technologies provide some insights, they still have significant shortcomings in addressing the advanced security mechanisms of modern applications.

[0004] Existing system property customization solutions (such as Xposed / Magisk-like modules based on application incubator (Zygote) injection or application framework layer hooks) typically require a high degree of intrusion into the upper-level Java runtime environment. This approach not only easily triggers the target application's internal sandbox security mechanisms and anti-Hook detection, resulting in severely insufficient stealth; but also, when dealing with a large number of property reads in high-concurrency scenarios, frequent inter-process communication (IPC) calls can cause significant performance bottlenecks, easily leading to system instability. Finally, traditional hooking techniques struggle to cover the isolation of native system property dictionary traversal (such as __system_property_foreach), easily leading to leakage of the underlying property tree traversal view. Summary of the Invention

[0005] To address the technical problems of existing Android systems, such as the inability to dynamically and finely customize and isolate system attributes for specific applications, and the lack of efficient and covert access control mechanisms when applications request system attributes, this invention provides a method for dynamic isolation and access control of Android system attributes based on shared memory. This method achieves the technical effects of virtualized access control for read-only system attributes, high performance and low latency, fine-grained access control, high covertness and strong compatibility.

[0006] The technical problem this invention aims to solve is that existing Android systems cannot achieve dynamic, fine-grained customization and isolation of read-only system attributes such as RO (Route) for specific applications, especially untrusted user applications. When applications request system attributes through precise queries or attribute traversal, there is a lack of efficient and covert access control mechanisms, resulting in the inability to effectively hide or replace real system fingerprint data in privacy compliance checks or sandbox isolation scenarios. Traditional Hook techniques often require intrusion into the core system framework, easily causing system instability and being easily detected by application security mechanisms, failing to meet the requirements for high concealment and high-performance dynamic attribute isolation.

[0007] The technical solution adopted by this invention to solve its technical problem is: providing an Android system attribute dynamic isolation and access control method, applied in an operating system including background daemons and system attribute shared memory, wherein the target application process can call the underlying runtime library of the operating system to initiate a system attribute access request; characterized in that the attribute access logic of the underlying runtime library is extended and redirected, including the following steps:

[0008] When the access request is an exact query request carrying the name of the system attribute to be queried, the underlying runtime library intercepts the request and obtains the user identifier of the target application process;

[0009] First, based on the user identifier, it is determined whether the target application process belongs to the system core service; when the user identifier is less than a preset system-level threshold and not equal to a preset terminal process identifier, it is determined to be a system core service; if it does not belong to the system core service, the memory mapping record of the target application process is further read; if the memory mapping record contains a preset untrusted path, it is determined to be an untrusted application, otherwise it is determined to be a trusted application.

[0010] When an application is determined to be a trusted application, the system's native attribute retrieval interface returns the actual system attribute result.

[0011] When an application is determined to be untrusted, the underlying runtime library reads the system attribute shared memory maintained by the background daemon process through memory mapping. The system attribute shared memory is configured with lockless sequential locks, and during the reading, the sequence number corresponding to the lockless sequential lock is compared with the sequence number status before and after the reading to ensure data consistency. If the sequence number indicates that concurrent writing has occurred, a spin retry mechanism is triggered.

[0012] The system attribute shared memory maintains a preset virtual control attribute key-value pair as a strict mode on / off state;

[0013] If a custom configuration data matching the system attribute name exists in the shared memory of the system attribute and is active, wherein the custom configuration data adopts an alignment structure compatible with the system native attribute structure in terms of memory layout, then the custom configuration data is returned.

[0014] If the custom configuration data is not matched or is matched but is inactive, the system returns the actual system attribute result through the system's native attribute retrieval interface when the strict mode is off; when the strict mode is on, the underlying runtime library directly returns the information that the attribute does not exist, thus blocking the behavior of returning the actual system attribute result in a fallback state.

[0015] The underlying runtime library is specifically the basic C library in the Android system;

[0016] For system property traversal requests initiated by untrusted applications, the underlying runtime library constructs a traversal proxy context and registers proxy callback functions with the underlying system.

[0017] When the proxy callback function is triggered during the traversal of the system's native attributes, if the strict mode is enabled and there is no corresponding entry for the current native attribute in the shared memory of the system attributes, the callback for the current native attribute is interrupted.

[0018] If the current native attribute has a corresponding entry in the system attribute shared memory and is marked as deleted, then the current native attribute is discarded and the callback is skipped;

[0019] If the current native attribute has a corresponding entry in the system attribute shared memory and is in an active state, then by taking advantage of the memory layout compatibility between the corresponding entry in the system attribute shared memory and the system native attribute structure, the native attribute pointer is replaced with a pointer to the corresponding entry in the system attribute shared memory, and the processed pointer is handed over to the original callback function passed by the target application for execution.

[0020] After the system's native attributes have been traversed, the underlying runtime library independently traverses the shared memory of the system attributes and appends the newly added and active custom configuration data back to the original callback function.

[0021] Optionally, the method further includes a privileged bypass mechanism, specifically:

[0022] Before the underlying runtime library performs credibility verification, if it is detected that the system attribute name carried by the query request starts with a preset bypass feature identifier string, the prefix string is truncated by zero copy through pointer offset at the underlying level, and the truncated real attribute name is handed over to the system's native attribute acquisition interface for querying. The obtained real system attribute result is directly returned to the target application process, thereby directly bypassing the query restrictions on the shared memory.

[0023] Preferably, the background daemon process and the configuration distribution terminal establish a communication link through a Unix domain socket;

[0024] The background daemon process receives dynamically issued instructions based on a preset structured data format (such as JSON format), and the instructions include adding attributes, updating attributes, deleting attributes, or clearing and resetting operations;

[0025] The background daemon updates the configuration data in the shared memory based on the received instructions, using atomic operations and a lock-free sequential locking mechanism.

[0026] The beneficial effects of this invention are compared with those of the prior art:

[0027] Enhanced stealth and application-layer transparency: Compared to existing attribute tampering schemes based on application framework layers or runtime dynamic injection, this invention directly extends source code-level query logic at the operating system's underlying runtime library. This solution remains transparent to the upper-layer application framework and native layer code, avoiding triggering the application's internal sandbox security mechanisms and anti-Hook detection, and providing higher environmental consistency in privacy compliance detection and fingerprint isolation scenarios.

[0028] High performance and low latency brought by lock-free architecture: This invention introduces shared memory access in the underlying runtime library and combines lock-free sequential lock (SeqLock) and memory mapping (mmap) mechanism to read configuration, avoiding the performance overhead caused by frequent inter-process communication (IPC) in high-concurrency attribute reading scenarios, reducing the response latency of attribute queries, and improving the stability of the system in high-concurrency scenarios.

[0029] Fine-grained on-demand isolation and high compatibility: By sinking control logic to the Bionic libc level and combining it with trustworthiness authentication based on user identifiers and process memory mapping paths, the system's core components and untrusted user applications are distinguished; the combination of bypass mechanisms and strict mode enables precise isolation control for specific targets, avoiding unintended impacts on the global environment.

[0030] Complete system property access view isolation: In addition to implementing isolation for precise system property queries, this invention also constructs a proxy callback mechanism for system property traversal requests. When strict mode is enabled, callbacks are interrupted for native properties that do not exist in the system property shared memory configuration. By replacing native property pointers, skipping deleted entries, and appending newly added properties, consistent isolation between the precise query path and the property traversal path is achieved, preventing untrusted applications from obtaining unauthorized real system properties through the traversal interface. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This invention provides a schematic diagram of a system architecture and data flow based on shared memory-based dynamic isolation of system attributes.

[0033] Figure 2 A schematic diagram illustrating the isolation and processing flow of a single system attribute query (get / find) provided in an embodiment of the present invention;

[0034] Figure 3 This is a schematic diagram of the native callback proxy and redirection process for system property traversal (foreach) provided in an embodiment of the present invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0036] Example 1: Initialization and Low-Level Authentication of a Shared Memory-Based Attribute Isolation System

[0037] Combination Figure 1 and Figure 2 As shown, this embodiment describes a dynamic isolation method that extends attribute query logic at the Android operating system's underlying runtime library (libc.so) level and interacts with a background daemon through shared memory. To ensure high system stability and effectively circumvent application-layer security detection mechanisms, the isolation logic in this embodiment does not employ traditional dynamic hooking techniques (such as PLT / GOT injection). Instead, within the Android Open Source Project (AOSP) environment, it directly customizes the underlying attribute reading entry point source code of the Bionic library and recompiles it to generate a system image. This method operates directly on the underlying runtime, eliminating the need for external modules to intercept upper-layer Java Framework APIs, resulting in extremely high stealth and execution efficiency.

[0038] Step 101: System Environment Initialization and Shared Memory Pool Construction

[0039] In environments with system privileges or custom system configurations, the system configures and automatically starts a background daemon process via the underlying init.rc initialization script, ensuring that this daemon process can run in an independent privileged process space from the initial system startup. This daemon process internally requests and maintains a shared memory block of a preset size (e.g., supporting thousands of attribute configurations) (preferably mounted at / dev / mock_props). The header structure of this shared memory contains a magic word (e.g., 0x4D4F434B, i.e., "MOCK") and the sequence number corresponding to the lockless sequence lock.

[0040] Step 102: Construct an attribute entry structure compatible with Bionic library features

[0041] To ensure complete transparency to the upper-level Java / Kotlin framework, each custom property entry (MockPropEntry) in shared memory must strictly mimic the native property structure of the Android system in terms of memory layout. Specifically, the common part of the entry contains an atomic serial number, a union storing the property value (supporting fixed-length short property values ​​or long property structures containing offsets and error information), and a character array storing the property name.

[0042] Building upon this, the structure is extended with private control fields at the end, including: attribute name length (name_len), attribute value length (value_len), a deletion flag indicating the deletion status (is_deleted), and an activation flag indicating the active or inactive status (is_active). Finally, a padding mechanism ensures that the memory address of the next entry meets the 8-byte alignment requirement, thereby guaranteeing memory safety and access efficiency at the system's underlying level when performing type casting and pointer reads.

[0043] Step 103: Establish a dynamic communication link between the daemon process and the control terminal.

[0044] The background daemon and the configuration distribution terminal establish a communication link via a Unix domain socket, with the socket path set to / dev / socket / mock_control. The daemon listens to this socket in real time, receiving control protocols in JSON format. For example, when executing the random test add command `su -c 'echo "{\"cmd\":\"add\", \"name\":\"ro.test.mock\", \"value\":\"123\"}" | nc -U / dev / socket / mock_control'`, the daemon parses the JSON data, updates the corresponding entry in shared memory through atomic operations, and updates the lock-free sequence lock state before and after the write.

[0045] Step 104: The target application initiates attribute query and privileged bypass mechanism detection (Magic Bypass).

[0046] The target application process invokes the `__system_property_find` or `__system_property_get` functions in the underlying runtime library to initiate a system property query. To ensure the absolute priority of the system debugging component, the underlying runtime library first independently performs privileged bypass detection before performing any trust authentication. Specifically, the underlying runtime library first parses the queried property name. If the name begins with a preset bypass feature identifier string, the underlying runtime library will automatically truncate the prefix (e.g., converting `MAGICro.build.version.sdk` to `ro.build.version.sdk`), and directly query the actual property space of the Android underlying layer, returning the actual value to the target process, directly bypassing subsequent shared memory queries and strict mode. This mechanism ensures that the system debugging component can obtain the true underlying fingerprint in any isolation mode.

[0047] It should be noted that MAGIC mentioned here is only a specific embodiment of the bypass identifier prefix. In actual applications, any preset string can be used as the identifier prefix.

[0048] Step 105: Application process trustworthiness verification (whitelist strategy)

[0049] If the bypass mechanism is not triggered, the underlying runtime library identifies its trustworthiness by reading process information:

[0050] User Identifier (UID) Exemption Detection: Call getuid() to obtain the process UID. If the UID is less than the preset threshold of 10000 (i.e., the core system service) and not 2000 (i.e., the preset terminal process identifier, such as the Shell process), it is determined to be absolutely trustworthy, and access to its real attributes is directly allowed.

[0051] Memory-mapped file detection: For processes with a UID greater than or equal to 10000, read their / proc / self / maps (memory-mapped) file. If an APK (Android application package) file containing the path / data / app / or / data / user / is found in the mapping records, it is determined to be an untrusted user application; if only the paths / system / , / vendor / , or / apex / are found, it is determined to be a trusted pre-installed application.

[0052] Step 106: Reading isolation attributes under the lock-free sequential lock (SeqLock) mechanism

[0053] The underlying runtime library reads the shared memory ` / dev / mock_props` via mmap mapping only when the target process is determined to be an untrusted user application. Before reading specific attribute configurations, the underlying runtime library first reads the sequence number (Start Sequence) corresponding to the lock-free sequential lock. If the sequence number is odd, it indicates that a background daemon process is performing a write operation, and the underlying runtime library triggers a spin retry; if it is even, it reads the corresponding attribute name, attribute value, and active or inactive state. After reading, the sequence number corresponding to the lock-free sequential lock is compared again. If it has changed, it indicates that the data was modified during the reading process, and it needs to be read again.

[0054] Example 2: Strict Mode and Attribute Mandatory Masking Strategy

[0055] Based on Example 1, further reference Figure 2 In the strict mode detection branch, this embodiment further illustrates how to achieve high-intensity environmental sandbox isolation (i.e., "strict mode").

[0056] Step 201: Enable Strict Mode

[0057] The system maintains a global strict mode switch in shared memory, with the corresponding virtual attribute name being sanjiu.mock_strict. This strict mode can be disabled directly via the adb shell command line, for example, by sending the command `adb shell su -c 'echo "{\"cmd\":\"add\", \"name\":\"sanjiu.mock_strict\", \"value\":\"0\"}" | nc -U / dev / socket / mock_control'` to turn off the isolation restriction.

[0058] Step 202: Strict Mode-Based Mandatory Access Control

[0059] When an untrusted application initiates an attribute query, the underlying runtime library completes identity authentication and then checks the status of sanjiu.mock_strict.

[0060] Strict mode off (default): If the attribute queried by the application is not found in shared memory (i.e. not specifically mocked), the underlying runtime library degrades to querying the underlying real system attribute and returning it.

[0061] Strict mode enabled: The underlying runtime library enforces a "whitelist" control mechanism. If the attribute queried by the application (including read-only system attributes such as ro.) is not matched in the shared memory configuration list, the underlying runtime library directly blocks the query and forces the return of information indicating that the attribute does not exist (null value), completely shielding the application from any real underlying attributes not in the Mock list, and preventing the leakage of the system's real fingerprint.

[0062] It should be noted that in the above embodiments, sanjiu.mock_strict is only a specific embodiment of the strict mode switch state in the virtual attribute name, and those skilled in the art can configure it to any other legal attribute name.

[0063] Example 3: Isolation Control of Property Traversal (Foreach) Based on Callback Delegation

[0064] like Figure 3 As shown, in the Android system, in addition to precise queries, applications also iterate through underlying properties using the `__system_property_foreach` function. Since this native interface directly passes pointers to the underlying native property structure to the callback function, traditional Hook techniques struggle to achieve dynamic replacement during the iteration process. This embodiment proposes a iteration isolation method based on a callback proxy.

[0065] Step 301: Construct the traversal proxy context

[0066] When an untrusted application calls __system_property_foreach, the underlying runtime library no longer directly executes the system's native traversal. Instead, it constructs a proxy context (ForeachCtx) to encapsulate and store the user's original callback function (user_cb) and user parameters (user_cookie) passed in by the target application.

[0067] Step 302: Proxy Traversal and Real-time Dynamic Replacement

[0068] The underlying runtime library registers a proxy callback function (ProxyCallback) with the system's native property dictionary. When the system iterates through the native property dictionary and triggers the proxy callback:

[0069] Status and preset filtering rule set verification: The underlying runtime library first extracts the name of the current native attribute. If it determines that the preset filtering rule set is matched (e.g., containing a specific manufacturer tracking ID or sanjiu identifier), the current callback is directly interrupted and hidden.

[0070] Strict mode coordination: If strict mode is enabled, further check if the native property exists in the shared memory's Mock list; if not, interrupt the callback directly.

[0071] Attribute state replacement: If a corresponding entry for the attribute exists in shared memory and is marked as deleted (is_deleted is true), the underlying runtime library discards the attribute. If it is active (is_active is true), the underlying runtime library safely replaces the pointer to the native attribute structure passed from the underlying layer with a pointer to the corresponding MockPropEntry in shared memory, and then passes it to the user's original callback function encapsulated in ForeachCtx for execution. This replacement process is completed in real time directly within the internal callback chain of __system_property_foreach, which not only does not break the compatibility of Bioniclibc's ABI (Application Binary Interface), but also strictly maintains the consistency of the underlying errno and thread-local storage (TLS) and other internal states, which is something that conventional application-layer hook techniques cannot achieve.

[0072] Step 303: Append traversal of added custom attributes

[0073] After the native system property dictionary has been traversed, the underlying runtime library independently traverses the shared memory space maintained by the background daemon. For system properties that exist in the shared memory and are not marked as deleted, but are newly added by the user, the underlying runtime library returns their pointers to the user's original callback function. Through these steps, seamless expansion, redirection, and isolation of the underlying property tree traversal view are achieved.

[0074] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0075] In this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or order; the term "multiple" refers to two or more unless otherwise explicitly defined. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. The terms "install," "connect," "link," "fix," etc., should be interpreted broadly. For example, "connect" can be a fixed connection, a detachable connection, or an integral connection; "link" can be a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0076] In the description of this invention, it should be understood that the terms "upper" and "lower" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or unit referred to must have a specific orientation or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0077] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for dynamic isolation and access control of Android system attributes, applied in an operating system including background daemons and shared memory for system attributes, wherein a target application process can call the underlying runtime library of the operating system to initiate a system attribute access request; characterized in that, The attribute access logic of the underlying runtime library is extended and redirected, including the following steps: When the access request is an exact query request carrying the name of the system attribute to be queried, the underlying runtime library intercepts the request and obtains the user identifier of the target application process; First, based on the user identifier, it is determined whether the target application process belongs to the system core service; when the user identifier is less than a preset system-level threshold and not equal to a preset terminal process identifier, it is determined to be a system core service; if it does not belong to the system core service, the memory mapping record of the target application process is further read; if the memory mapping record contains a preset untrusted path, it is determined to be an untrusted application, otherwise it is determined to be a trusted application. When an application is determined to be a trusted application, the system's native attribute retrieval interface returns the actual system attribute result. When an application is determined to be untrusted, the underlying runtime library reads the system attribute shared memory maintained by the background daemon process through memory mapping. The system attribute shared memory is configured with lockless sequential locks, and during the reading, the sequence number corresponding to the lockless sequential lock is compared with the sequence number status before and after the reading to ensure data consistency. If the sequence number indicates that concurrent writing has occurred, a spin retry mechanism is triggered. The system attribute shared memory maintains a preset virtual control attribute key-value pair as a strict mode on / off state; If a custom configuration data matching the system attribute name exists in the shared memory of the system attribute and is active, wherein the custom configuration data adopts an alignment structure compatible with the system native attribute structure in terms of memory layout, then the custom configuration data is returned. If the custom configuration data is not matched or is matched but is inactive, the system returns the actual system attribute result through the system's native attribute retrieval interface when the strict mode is off; when the strict mode is on, the underlying runtime library directly returns the information that the attribute does not exist, thus blocking the behavior of returning the actual system attribute result in a fallback state. The underlying runtime library is specifically the basic C library in the Android system; For system property traversal requests initiated by untrusted applications, the underlying runtime library constructs a traversal proxy context and registers proxy callback functions with the underlying system. When the proxy callback function is triggered during the traversal of the system's native attributes, if the strict mode is enabled and there is no corresponding entry for the current native attribute in the shared memory of the system attributes, the callback for the current native attribute is interrupted. If the current native attribute has a corresponding entry in the system attribute shared memory and is marked as deleted, then the current native attribute is discarded and the callback is skipped; If the current native attribute has a corresponding entry in the system attribute shared memory and is in an active state, then by taking advantage of the memory layout compatibility between the corresponding entry in the system attribute shared memory and the system native attribute structure, the native attribute pointer is replaced with a pointer to the corresponding entry in the system attribute shared memory, and the processed pointer is handed over to the original callback function passed by the target application for execution. After the system's native attributes have been traversed, the underlying runtime library independently traverses the shared memory of the system attributes and appends the newly added and active custom configuration data back to the original callback function.

2. The method according to claim 1, characterized in that, The method also includes a privileged bypass mechanism: Before the underlying runtime library performs credibility verification, if it is detected that the system attribute name carried by the query request starts with a preset bypass feature identifier string, the prefix string is truncated by zero copy through pointer offset at the underlying level, and the truncated real attribute name is handed over to the system's native attribute acquisition interface for querying. The obtained real system attribute result is directly returned to the target application process, thereby directly bypassing the query restrictions on the shared memory.

3. The method according to claim 1, characterized in that, The background daemon process and the configuration distribution terminal establish a communication link through a Unix domain socket; The background daemon process receives dynamically issued instructions based on a preset structured data format; The instructions include adding attributes, updating attributes, deleting attributes, or clearing / resetting operations; The background daemon updates the configuration data in the shared memory based on the received instructions, using atomic operations and a lock-free sequential locking mechanism.

Images