Method for isolating server hook based on sandbox

Abstract

The invention discloses a method for isolating a server hook based on a sandbox, and according to the scheme, the security, the resource management efficiency and the isolation of Server hooks in a code management platform are remarkably improved, the defects in the aspects of resource consumption, authority control and the isolation in the prior art are effectively overcome, and the efficient and safe management requirements on the Server hooks in a multi-tenant environment are met. By the adoption of the scheme, resource consumption can be saved, and quick starting can be achieved, the Isole sandbox can execute codes immediately, the whole mirror image does not need to be loaded in advance, and resource use of each process can be specifically and finely controlled, so that resource management is more efficient. The Isole sandbox realizes quick response and efficient resource utilization through lightweight resource management and independent process space, and meanwhile, the process of each tenant is ensured not to interfere with each other.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a method for isolating server-side hooks based on a sandbox. Background Art

[0002] With the rapid development of software technology and the increasing size of code bases, developers have an increasing demand for server hooks. As a key extension mechanism, server hooks are widely used in code management platforms to handle various server-side events. For example, during code push, update, and release, server hooks can trigger specific scripts at different stages to implement extended functions or meet custom requirements. However, since server hooks can directly operate server resources, once maliciously exploited or error codes are executed, it may have a serious impact on the security and stability of the system. Therefore, ensuring the security isolation and resource management of server hooks has become an urgent problem to be solved.

[0003] At present, domestic and foreign solutions for implementing server hooks isolation on code management platforms mainly rely on traditional virtualization or container technologies, such as Docker. Although these methods can provide a certain degree of isolation, they still have significant defects in resource-sensitive multi-tenant environments, including insufficient resource isolation, excessive resource consumption, lack of effective permission control, and poor isolation between multiple tenants. Especially in a resource-constrained server environment, these methods are difficult to effectively meet the system's requirements for stability, high performance, and flexibility. Summary of the invention

[0004] The present application provides a method based on sandbox isolation server hooks, aiming to solve the problem that the existing technology is difficult to effectively meet the system's requirements for stability, high performance and flexibility.

[0005] The present application provides a method for isolating a server hook based on a sandbox, the method comprising:

[0006] Server hooks isolation and resource management applied in a code management platform, characterized in that the method comprises:

[0007] Install sandbox dependencies, install the Isolate sandbox and corresponding target dependency components on the server system;

[0008] Create and configure sandbox instances, set the upper limit of the number of instances, configure environment variables, access permissions and file system mounts through DockerFile files; set resource limit parameters, configure control groups, CPU allocation ratios and memory limits for the sandbox instances; integrate the sandbox into the Gitaly service, and automatically start or stop the sandbox instance based on resource status and load;

[0009] Creating a sandbox through an independent process to isolate the execution permissions of untrusted code, and cleaning the cache and initializing the default state before starting the sandbox;

[0010] Setting memory limit parameters for the sandbox instance, executing a specified program in the sandbox, and redirecting input and output to a buffer;

[0011] Read and parse resource usage information and dynamically adjust configuration.

[0012] In the above solution, optionally, the installation sandbox dependency includes:

[0013] Download the required basic images, install the components required for the Isolate sandbox operating environment, and configure dependencies to ensure that the sandbox environment can run independently and be isolated from other services of the code management platform;

[0014] The creation and configuration of the sandbox instance includes using the DockerFile file to configure the environment variables of each sandbox instance, setting network access permissions and file system mount points, and assigning a unique identifier to each sandbox instance through an automated script when the sandbox is started.

[0015] In the above solution, optionally, the setting of the resource restriction parameter specifically includes:

[0016] Configure the CPU allocation ratio so that the CPU usage of each sandbox instance meets the preset ratio;

[0017] Set a memory cap to limit the memory usage of each sandbox instance through control group parameters;

[0018] Limit the disk I / O operations of sandbox instances to ensure resource fairness in a multi-tenant environment.

[0019] In the above solution, optionally, integrating the sandbox into the Gitaly service and automatically starting or stopping the sandbox instance according to resource status and load includes:

[0020] The sandbox scheduling strategy is set in the Gitaly service. Gitaly calls the automatic scheduling module to dynamically adjust the number of sandboxes and allocate resources according to the current system resource status and load, so as to avoid uneven resource allocation when the system load is too high.

[0021] In the above solution, optionally, creating a sandbox through an independent process to isolate the execution permission of untrusted code includes:

[0022] When executing Server hooks, an independent process is created, which is used to create an isolated sandbox environment and restrict its access to system resources according to the sandbox permission settings, ensuring that untrusted code can only run in an independent sandbox and cannot pose a potential threat to the system.

[0023] In the above scheme, optionally, clearing the cache and initializing the default state before starting the sandbox includes ensuring that the operating environment in the sandbox is restored to the default state by clearing temporary files and cached data in the sandbox instance before starting the sandbox instance, and ensuring that the state of the sandbox instance is stable at startup by reallocating initial resource parameters.

[0024] In the above solution, optionally, setting memory limit parameters for the sandbox instance includes:

[0025] Use the strconv method in the Go language standard library to set the memory limit parameter for the sandbox instance. The parameter format is "--cg-mem=memory size", and write the configuration file to the resource configuration file of the sandbox instance to keep a consistent memory usage upper limit for the sandbox instance during operation.

[0026] In the above solution, optionally, executing a specified program in the sandbox and redirecting input and output to a buffer includes:

[0027] Redirect the standard input, standard output, and error output of the sandbox instance to the specified buffer to record the output information during program execution. Monitor the status of program execution through the exec.Command() method during the sandbox running process for real-time debugging and logging when necessary.

[0028] In the above solution, optionally, the reading and parsing of resource usage information and dynamically adjusting the configuration includes:

[0029] During the sandbox execution process, the temporary metadata file is opened to parse the resource usage of the sandbox instance, including the maximum memory usage, CPU consumption, and execution time; and the state parameters of the sandbox instance are dynamically adjusted according to the parsed resource data to optimize resource configuration.

[0030] In the above solution, optionally, the method further includes:

[0031] Clean up the sandbox instance. Specifically, after the sandbox instance ends, perform a cleanup operation by marking the "--cleanup" parameter to clean up the sandbox, and store the log information of the cleanup operation, including the specific parameters passed to the sandbox, the cleanup completion status, and the resource release status, in the system log file.

[0032] Compared with the prior art, this application has at least the following beneficial effects:

[0033] Based on further analysis and research of existing technical problems, this application recognizes that it is difficult for existing technologies to effectively meet the system's requirements for stability, high performance and flexibility. This application provides a method that can save resource consumption and better isolate data between different tenants. By installing the Isolate sandbox and setting resource restriction parameters such as control groups, CPU allocation ratios and memory limits, each Server hooks instance is provided with independent resource allocation and isolation environments. Compared with traditional virtualization methods, this solution is lighter, effectively reduces resource consumption, ensures resource independence in a multi-tenant environment, and achieves fairness when sharing resources. In terms of security, an isolated sandbox environment is created through an independent process, and the execution permissions of untrusted code are strictly controlled to improve system security and solve the problem of insufficient permission control. In terms of dynamic management, the sandbox is integrated into the Gitaly service, and dynamic scheduling is achieved based on the system resource status and load, which improves resource utilization, reduces resource competition during high load, and avoids uneven resource allocation. In terms of stability, cache cleaning and initialization are performed before starting the sandbox to ensure a clean and stable environment, improve system stability, and avoid the impact of residual data. In terms of resource monitoring and dynamic adjustment, the use of sandbox resources is monitored in real time, the configuration is adjusted dynamically, the system load is balanced, excessive resource consumption is avoided, and resource management is refined. In terms of automated cleanup and logging, the sandbox is automatically cleaned up and the operation log is recorded after execution to ensure effective resource recovery, prevent resource leakage, improve resource utilization efficiency, and avoid resource waste.

[0034] This method significantly improves the security, resource management efficiency and isolation of Server hooks in the code management platform, effectively solves the shortcomings of existing technologies in resource consumption, permission control and isolation, and meets the needs of efficient and secure management of Server hooks in a multi-tenant environment.

[0035] The application solution can save resource consumption and start quickly: the Isolate sandbox can execute code immediately without preloading the entire image, and can control the resource usage of each process in detail, which makes resource management more efficient. Better isolation in a multi-tenant environment: The Isolate sandbox achieves fast response and efficient resource utilization through lightweight resource management and independent process space, while ensuring that the processes of each tenant do not interfere with each other. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] FIG1 is a flow chart of a method for isolating a server hook based on a sandbox according to an embodiment of the present application;

[0037] Figure 2 A schematic diagram of the architecture of a method for isolating a server hook based on a sandbox according to an embodiment of the present application;

[0038] FIG3 is a practical interaction diagram of a method based on sandbox isolation server hook provided by an embodiment of the present application. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0040] In one embodiment, Figure 1 As shown, a method for isolating server hooks based on sandbox is provided, which is applied to server hooks isolation and resource management in the code management platform, including the following steps:

[0041] Install sandbox dependencies, install the Isolate sandbox and corresponding target dependency components on the server system;

[0042] Create and configure sandbox instances, set the upper limit of the number of instances, configure environment variables, access permissions and file system mounts through DockerFile files; set resource limit parameters, configure control groups, CPU allocation ratios and memory limits for the sandbox instances; integrate the sandbox into the Gitaly service, and automatically start or stop the sandbox instance based on resource status and load;

[0043] Creating a sandbox through an independent process to isolate the execution permissions of untrusted code, and cleaning the cache and initializing the default state before starting the sandbox;

[0044] Setting memory limit parameters for the sandbox instance, executing a specified program in the sandbox, and redirecting input and output to a buffer;

[0045] Read and parse resource usage information and dynamically adjust configuration.

[0046] This embodiment proposes a server hooks management method based on sandbox isolation, which is suitable for server hooks isolation and resource management in the code management platform. Its technical effects are mainly reflected in the following aspects, which can effectively solve the shortcomings of the existing technology in the background technology:

[0047] Efficient resource isolation: By installing the Isolate sandbox and setting resource restriction parameters such as control groups (Cgroups), CPU allocation ratios, and memory limits, this method provides independent resource allocation and isolation environments for each Server hooks instance. Compared with traditional virtualization methods, this solution is more lightweight, effectively reduces resource consumption, and ensures the resource independence of each sandbox instance in a multi-tenant environment, thereby achieving fairness when multiple users share system resources.

[0048] Secure permission control: This method creates an isolated sandbox environment through independent processes, strictly controls the execution permissions of untrusted code, and ensures that Server hooks are executed in an isolated environment. This avoids the risk of untrusted code directly accessing system resources, improves the overall security of the system, and solves the problem of insufficient permission control in traditional isolation methods.

[0049] Flexible dynamic management: The sandbox is integrated into the Gitaly service, and dynamic scheduling is implemented based on the system resource status and load. The sandbox instance can be automatically started or stopped according to the current system resource status. This dynamic management mechanism not only improves the resource utilization of the system, but also reduces resource competition through automatic scheduling when the server load is high, avoiding the problem of uneven resource allocation caused by excessive system load.

[0050] Stable sandbox operating environment: This method performs cache cleaning and initialization operations before starting the sandbox instance, ensuring the cleanliness and stability of the sandbox environment and ensuring that each Server hook is in a consistent operating environment during execution, thereby improving the stability of the system and avoiding the problem of the sandbox environment being affected by residual data.

[0051] Real-time resource monitoring and dynamic adjustment: By reading and parsing the resource usage information of the sandbox instance, including maximum memory usage, CPU consumption, and execution time, the system can dynamically adjust the sandbox configuration according to resource consumption, thereby better balancing the system load, avoiding excessive resource consumption, and achieving refined resource management.

[0052] Automatic cleanup and logging: This method automatically cleans up after the sandbox instance is executed and records detailed operation logs, including cleanup parameters, completion status, and resource release, to ensure effective recycling of system resources and prevent resource leakage. This automatic cleanup mechanism can improve the resource utilization efficiency of the system and avoid the waste of resources caused by frequent creation and deletion of sandbox instances in traditional methods.

[0053] This embodiment significantly improves the security, resource management efficiency and isolation of Server hooks in the code management platform, can effectively solve the deficiencies of the existing technology in terms of resource consumption, permission control and isolation, and meets the code management platform's requirements for efficient and secure management of Server hooks in a multi-tenant environment.

[0054] In this embodiment, the installation sandbox dependency includes:

[0055] Download the required basic images, install the components required for the Isolate sandbox operating environment, and configure dependencies to ensure that the sandbox environment can run independently and be isolated from other services of the code management platform;

[0056] The creation and configuration of the sandbox instance includes using the DockerFile file to configure the environment variables of each sandbox instance, setting network access permissions and file system mount points, and assigning a unique identifier to each sandbox instance through an automated script when the sandbox is started.

[0057] In this embodiment, the setting of the resource restriction parameters specifically includes:

[0058] Configure the CPU allocation ratio so that the CPU usage of each sandbox instance meets the preset ratio;

[0059] Set a memory cap to limit the memory usage of each sandbox instance through control group parameters;

[0060] Limit the disk I / O operations of sandbox instances to ensure resource fairness in a multi-tenant environment.

[0061] This embodiment solves the resource allocation and competition problems in a multi-tenant environment through refined resource restriction measures. Reasonable restrictions on CPU, memory, and disk I / O enable each sandbox instance to maintain independence and controllability in resource usage, improve the resource management efficiency of the system, and ensure that the Server hooks instance can still run stably under resource constraints.

[0062] In this embodiment, the sandbox is integrated into the Gitaly service, and the sandbox instance is automatically started or stopped according to the resource status and load, including:

[0063] The sandbox scheduling strategy is set in the Gitaly service. Gitaly calls the automatic scheduling module to dynamically adjust the number of sandboxes and allocate resources according to the current system resource status and load, so as to avoid uneven resource allocation when the system load is too high.

[0064] This embodiment realizes elastic resource allocation and optimized management of sandbox instances through dynamic management and priority scheduling, which can reduce resource waste while meeting high concurrency requirements, ensure reasonable allocation of system resources under different load conditions, and improve the overall performance and responsiveness of the system.

[0065] In this embodiment, creating a sandbox through an independent process to isolate the execution permission of untrusted code includes:

[0066] When executing Server hooks, an independent process is created, which is used to create an isolated sandbox environment and restrict its access to system resources according to the sandbox permission settings, ensuring that untrusted code can only run in an independent sandbox and cannot pose a potential threat to the system.

[0067] In this embodiment, cleaning the cache and initializing the default state before starting the sandbox includes ensuring that the operating environment in the sandbox is restored to the default state by clearing temporary files and cached data in the sandbox instance before starting the sandbox instance, and ensuring that the state of the sandbox instance is stable at startup by reallocating initial resource parameters.

[0068] This embodiment provides a clean operating condition for the startup of the sandbox environment through cache management and initialization mechanisms, effectively avoiding the impact of cache residues or file conflicts on the execution process of Server hooks. Specifically, before each sandbox instance is started, the present invention ensures that the sandbox environment is in the default state by clearing temporary files and cached data in the sandbox. The main technical effect of this operation is to prevent previously executed code from leaving data traces or caches in the sandbox, avoiding them from interfering with the execution of the current task. For the code management platform, the operating environment of each Server hooks instance must be clean and repeatable, otherwise the state data of the cache residue may cause errors in the execution logic, and even cause functional abnormalities. Therefore, this embodiment realizes the reset of the sandbox environment through cache cleaning, ensuring that each Server hooks instance has an independent operating environment when executed.

[0069] Another important technical effect of this embodiment is the initialization operation, which ensures that the resources of the sandbox are reasonably allocated when it is started by reallocating the initial resource parameters for each sandbox instance. This initialization mechanism can effectively improve the operating efficiency and stability of the sandbox and avoid the problem of uneven system load caused by resource competition. For example, by initializing the memory, CPU and I / O resource configuration, the system can set the resource consumption upper limit of the sandbox in advance to prevent a single task from accidentally occupying too many resources and affecting the execution of other tasks. This initialization mechanism also enables the sandbox to have appropriate resource allocation when it is started, without the need to temporarily adjust resource allocation during execution, thereby improving the performance of the system.

[0070] Through the cache management and initialization settings of this embodiment, the independence and execution consistency of the sandbox environment are guaranteed, so that Server hooks can obtain a consistent execution environment each time they are executed, avoiding execution result deviations due to environmental differences. This technical effect is particularly important in a multi-tenant environment, because each tenant may execute a different Server hooks instance, and the cache cleaning and initialization operations ensure the independence of the operating environment between each instance, eliminating the risk of cache contamination and data leakage. Therefore, this embodiment significantly improves the execution stability, operating efficiency and data security of the sandbox instance.

[0071] In this embodiment, setting memory limit parameters for the sandbox instance includes:

[0072] Use the strconv method in the Go language standard library to set the memory limit parameter for the sandbox instance. The parameter format is "--cg-mem=memory size", and write the configuration file to the resource configuration file of the sandbox instance to keep a consistent memory usage upper limit for the sandbox instance during operation.

[0073] In this embodiment, executing a specified program in the sandbox and redirecting input and output to a buffer includes:

[0074] Redirect the standard input, standard output, and error output of the sandbox instance to the specified buffer to record the output information during program execution. Monitor the status of program execution through the exec.Command() method during the sandbox running process for real-time debugging and logging when necessary.

[0075] In this embodiment, the reading and parsing of resource usage information and dynamically adjusting the configuration includes:

[0076] During the sandbox execution process, the temporary metadata file is opened to parse the resource usage of the sandbox instance, including the maximum memory usage, CPU consumption, and execution time; and the state parameters of the sandbox instance are dynamically adjusted according to the parsed resource data to optimize resource configuration.

[0077] In this embodiment, the method further includes:

[0078] Clean up the sandbox instance. Specifically, after the sandbox instance ends, perform a cleanup operation by marking the "--cleanup" parameter to clean up the sandbox, and store the log information of the cleanup operation, including the specific parameters passed to the sandbox, the cleanup completion status, and the resource release status, in the system log file.

[0079] In one embodiment, Server hooks has three types of hooks, namely pre-receive, update and post-receive. The functions of the three hooks are:

[0080] pre-receive: The script that is called first when processing a push operation from the client.

[0081] update: Similar to pre-receive, except that it runs the script once for each branch to be updated.

[0082] pre-receive: A script executed after the entire process is completed, used for subsequent operations such as updating system services and notifying users.

[0083] It can be seen that hooks allow developers to extend the functionality of applications without modifying the core code. So when the hook has a lot of permissions and is used maliciously, it will affect the entire system environment. Therefore, a sandbox environment can be used to execute these scripts, so that even if they are used maliciously, it will not affect the entire system.

[0084] Existing sandbox methods for isolation solutions of code management platforms generally have problems such as high resource consumption, insufficient resource isolation, lack of security, and inability to effectively ensure data isolation and privacy protection between different tenants. They are not suitable for code management platforms.

[0085] This embodiment provides a method that can save resource consumption and better isolate data between different tenants, especially in resource-sensitive or multi-tenant environments.

[0086] This embodiment provides an environment isolation sandbox that is both efficient and highly flexible: Isolate, such as Figure 2 As shown, the solution of this embodiment includes the following steps and customized functions:

[0087] Install sandbox dependencies and set the maximum number of boxes;

[0088] Use the DockerFile file to install, configure, and run sandbox dependencies.

[0089] Create a configuration file and configure the sandbox operating environment;

[0090] Use the configuration file to set the maximum number of control groups (Cgroups), CPU shares and quotas, memory bytes, etc. for the sandbox.

[0091] A sandbox runtime environment needs to be integrated into Gitaly.

[0092] Gitaly starts and stops the sandbox scheduling operation.

[0093] If you need to control the execution permissions of Server hooks, you need to start process A to create a sandbox environment when executing Server hooks to execute the client's untrusted code.

[0094] Create the main program and integrate the sandbox function;

[0095] The main program is written in Go language.

[0096] Clear the sandbox cache first, then initialize the sandbox.

[0097] Get the sandbox root directory through Go language and save it to the structure pointer.

[0098] Create a sandbox function:

[0099] Accepts a pointer to a structure that stores the sandbox.

[0100] Create a new sandbox instance and save it to the structure slice.

[0101] Returns the sandbox instance for easy chaining.

[0102] Set the memory quota for the sandbox:

[0103] Select the specified sandbox by the slice in which the sandbox is stored.

[0104] Configure the memory limit by adding the parameter starting with "--cg-mem=" to the standard library strconv in the Go language.

[0105] Run the specified program in the sandbox:

[0106] Select the specified sandbox in the slice where the sandbox is stored.

[0107] Start the sandbox process through exec.Command(), and point the standard input, output, and error output to the corresponding buffers or streams respectively.

[0108] Open and read the temporary metadata file, parse the information in it to obtain the resource consumption of the program when it is running (such as maximum memory usage, running time, etc.), and further adjust the sandbox status value according to the status information in the metadata.

[0109] Returns status and monitors its resource usage.

[0110] Clean up the sandbox function:

[0111] Gets a slice of storage sandboxes and selects a specified sandbox.

[0112] Use the standard library strconv in the Go language to add identifiers: "-b" specifies the ID of the isolated environment, and "--cleanup" indicates to perform a cleanup operation.

[0113] Records the log before the cleaning operation is performed, including the specific parameters passed to the sandbox command.

[0114] The key points of this embodiment are resource consumption, startup speed and isolation level.

[0115] Isolate sandbox is usually more lightweight because it does not need to load complex image layers, so it consumes less resources. Figure 3 As shown in the figure, after receiving the request, the Isolate sandbox will select an existing or create a new sandbox. It bypasses the image processing level, so the startup speed of the Isolate sandbox is usually faster.

[0116] Especially in environments with multi-tenant requirements such as code management platforms, the Isolate sandbox can use the Linux kernel's namespace and control group (Cgroups) technology to achieve permission isolation. These namespaces allow the creation of multiple independent environments within the same operating system.

[0117] This embodiment can save resource consumption and start quickly: the Isolate sandbox can execute code immediately without preloading the entire image, and can be fine-grained to control the resource usage of each process, which makes resource management more efficient. Better isolation in a multi-tenant environment: the Isolate sandbox achieves fast response and efficient resource utilization through lightweight resource management and independent process space, while ensuring that the processes between tenants do not interfere with each other.

[0118] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A method for isolating server hooks based on sandbox, applied to server hooks isolation and resource management in a code management platform, characterized in that: The method comprises: Install sandbox dependencies, install the Isolate sandbox and corresponding target dependency components on the server system; Create and configure sandbox instances, set the upper limit of the number of instances, configure environment variables, access permissions and file system mounts through DockerFile files; set resource limit parameters, configure control groups, CPU allocation ratios and memory limits for the sandbox instances; integrate the sandbox into the Gitaly service, and automatically start or stop the sandbox instance based on resource status and load; Creating a sandbox through an independent process to isolate the execution permissions of untrusted code, and cleaning the cache and initializing the default state before starting the sandbox; Setting memory limit parameters for the sandbox instance, executing a specified program in the sandbox, and redirecting input and output to a buffer; Read and parse resource usage information and dynamically adjust configuration.

2. The method according to claim 1, characterized in that The installation sandbox dependencies include: Download the required basic images, install the components required for the Isolate sandbox operating environment, and configure dependencies to ensure that the sandbox environment can run independently and be isolated from other services of the code management platform; The creation and configuration of the sandbox instance includes using the DockerFile file to configure the environment variables of each sandbox instance, setting network access permissions and file system mount points, and assigning a unique identifier to each sandbox instance through an automated script when the sandbox is started.

3. The method according to claim 1, characterized in that The resource restriction parameter settings specifically include: Configure the CPU allocation ratio so that the CPU usage of each sandbox instance meets the preset ratio; Set a memory cap to limit the memory usage of each sandbox instance through control group parameters; Limit the disk I / O operations of sandbox instances to ensure resource fairness in a multi-tenant environment.

4. The method according to claim 1, characterized in that: Integrating the sandbox into the Gitaly service and automatically starting or stopping the sandbox instance according to resource status and load includes: The sandbox scheduling strategy is set in the Gitaly service. Gitaly calls the automatic scheduling module to dynamically adjust the number of sandboxes and allocate resources according to the current system resource status and load, so as to avoid uneven resource allocation when the system load is too high.

5. The method according to claim 1, characterized in that The creation of a sandbox through an independent process to isolate the execution permissions of untrusted code includes: When executing Server hooks, an independent process is created, which is used to create an isolated sandbox environment and restrict its access to system resources according to the sandbox permission settings, ensuring that untrusted code can only run in an independent sandbox and cannot pose a potential threat to the system.

6. The method according to claim 1, characterized in that The method of cleaning up the cache and initializing the default state before starting the sandbox includes ensuring that the operating environment in the sandbox is restored to the default state by clearing temporary files and cached data in the sandbox instance before starting the sandbox instance, and ensuring that the state of the sandbox instance is stable at startup by reallocating initial resource parameters.

7. The method according to claim 1, characterized in that The setting of memory limit parameters for the sandbox instance includes: Use the strconv method in the Go language standard library to set the memory limit parameter for the sandbox instance. The parameter format is "--cg-mem=memory size", and write the configuration file to the resource configuration file of the sandbox instance to keep a consistent memory usage limit for the sandbox instance during operation.

8. The method according to claim 1, characterized in that Executing a specified program in the sandbox and redirecting input and output to a buffer includes: Redirect the standard input, standard output, and error output of the sandbox instance to the specified buffer to record the output information during program execution. Monitor the status of program execution through the exec.Command() method during the sandbox running process for real-time debugging and logging when necessary.

9. The method according to claim 1, characterized in that: The reading and parsing of resource usage information and dynamically adjusting configuration includes: During the sandbox execution process, the temporary metadata file is opened to parse the resource usage of the sandbox instance, including the maximum memory usage, CPU consumption, and execution time; and the state parameters of the sandbox instance are dynamically adjusted according to the parsed resource data to optimize resource configuration.

10. The method according to claim 1, characterized in that The method further comprises: Clean up the sandbox instance. Specifically, after the sandbox instance ends, perform a cleanup operation by marking the "--cleanup" parameter to clean up the sandbox, and store the log information of the cleanup operation, including the specific parameters passed to the sandbox, the cleanup completion status, and the resource release status, in the system log file.

Images