File monitoring method and electronic device

Abstract

The application provides a file monitoring method and an electronic device. The method comprises the following steps: during the running of a first operating system, changing a kernel code to replace an initial inotify event processing function in the kernel with a preset inotify event processing function; obtaining a target file operation event and target context information of a target file through the preset inotify event processing function; wherein the target file operation event and the target context information are determined by the preset inotify event processing function based on a preset first configuration file, and the first configuration file is used to record at least one target file; and recording the target file operation event and the target context information in a kernel log. By dynamically replacing the inotify event processing function and adding the context information of the file operation, the application can ensure that the key file operation is captured in time. In this way, during the problem positioning and troubleshooting process of the electronic device, the whole process of the event occurrence can be accurately restored, thereby greatly improving the maintainability of the system.

Description

Technical Field

[0001] This application relates to the field of data monitoring technology, and in particular to a file monitoring method and electronic device. Background Technology

[0002] During the operation of a Linux system, in order to facilitate problem localization, troubleshooting, and the fulfillment of certain functional requirements (such as security auditing, compliance checks, and tracking of abnormal behavior), it is necessary to monitor detailed information on file creation, modification, deletion, or access events, and record logs based on the detailed information so that the logs can be retrieved when needed.

[0003] Among related technologies, the inotify monitoring mechanism is commonly used to record file operation logs. Inotify, by setting listeners on files or directories, can monitor file creation, deletion, modification, and movement operations in real time and trigger corresponding event notifications.

[0004] However, traditional inotify has a limited event buffer, which may cause events to be lost if events are generated too quickly; when the monitored file is renamed or moved, the original listening point will become invalid and the file's listening point needs to be reset; therefore, traditional inotify is difficult to adapt to complex application scenarios. Summary of the Invention

[0005] This application provides a file monitoring method that, by dynamically replacing the inotify event handling function and adding context information for file operations, ensures the timely capture and recording of all critical file operations. This enables accurate reconstruction of the entire event process during problem localization and troubleshooting, thereby significantly improving system maintainability.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, embodiments of this application provide a file monitoring method applied to an electronic device, the method comprising:

[0008] The target file operation events and target context information for the target file are obtained through the preset inotify event handler function; wherein, the target file operation events and target context information are determined by the preset inotify event handler function based on a preset first configuration file, which is used to record at least one target file;

[0009] Record target file operation events and target context information in the kernel log.

[0010] Based on this solution, by dynamically modifying the kernel code during system runtime, the target files can be defined in batches based on configuration files using the replaced inotify event handling functions. The preset inotify event handling functions are used to capture and record all critical file operations in a timely manner. Compared with the traditional static configuration method of inotify, which requires modification of system-level listening logic, this solution supports the updating of monitoring rules during system runtime through a modular loading mechanism, avoiding the situation where listening points fail and need to be reset.

[0011] In one possible implementation, before modifying the kernel code during the first operating system's execution to replace the initial inotify event handler function in the kernel module with a preset inotify event handler function, the following is also included:

[0012] In response to the running of the first operating system, the kernel module is loaded; the kernel module includes a pre-defined inotify event handler function.

[0013] The first configuration file is read based on the kernel module.

[0014] Based on this solution, the pre-defined inotify event handling functions are dynamically loaded through the kernel module, and target files are defined in batches based on configuration files, thus enabling flexible deployment of monitoring rules.

[0015] In one possible implementation, during the execution of the first operating system, the kernel code is modified to replace the initial inotify event handler function in the kernel module with a preset inotify event handler function, including:

[0016] During the first operating system's operation, the kernel code is modified based on kernel hot patches or kernel probes to replace the initial inotify event handler function in the kernel module with a preset inotify event handler function.

[0017] Based on this solution, function logic can be dynamically modified at runtime through kernel hot patching or kernel probes. This avoids the problem of listener point failure caused by file renaming or moving (without needing to rebuild the inotify instance), significantly reduces the complexity of kernel module development and deployment, and improves the adaptability of the technical solution to complex application scenarios (such as containerized environments and dynamic file paths).

[0018] In one possible implementation, the target context information includes at least one of the following: user information of the user executing the target file operation event, process information of the process executing the target file operation event, and time information of the time of the target file operation event.

[0019] Based on this solution, the target context information is limited to include key metadata such as user, process, and time, which solves the problem of log volume expansion caused by full recording in traditional audit systems. By accurately associating file operation events with execution entity information, it reduces the storage of unnecessary data and optimizes log analysis efficiency while meeting security audit requirements (such as tracing the source of abnormal behavior).

[0020] In one possible implementation, the kernel module is generated based on compiled source code; in response to the running of a first operating system, the kernel module is loaded, including:

[0021] In response to the first operating system running, the insmod or modprobe command is invoked to load kernel modules into the kernel.

[0022] Based on this solution, the design of compiling and dynamically loading kernel modules decouples monitoring rule configuration from kernel-mode operation. Compared to the traditional audit configuration mode that relies on external scripts or professional tools, this solution uses the insmod / modprobe commands to achieve hot-swapping of rules, completing configuration updates while the system is running continuously, avoiding business interruption; at the same time, the kernel module directly operates on the inotify instance, avoiding the data copying overhead between user space and kernel space, and improving rule loading efficiency.

[0023] In one possible implementation, the first configuration file is read based on the kernel module, including:

[0024] The kernel module reads file information or a list of target files from the first configuration file.

[0025] Based on this solution, and using the associated file information and target file list in the first configuration file, batch monitoring of multiple target files is achieved. Compared to the inefficient operation of traditional inotify, which requires creating a separate monitoring point for each file, this solution reduces the number of system calls by parsing the file list through the kernel module and creating an inotify instance uniformly.

[0026] In one possible implementation, after the kernel module reads the first configuration file, it also includes:

[0027] The kernel module creates an inotify instance corresponding to the target file based on file information or a list of target files, and sets descriptors in the inotify instance, including watch descriptors.

[0028] Based on this solution, an independent inotify instance is created for each target file and a descriptor is set, resolving the resource contention and false alarm issues caused by traditional global inotify monitoring. Instance isolation captures only events directly related to the target file, avoiding interference from irrelevant events. The descriptor-file handle binding mechanism allows for quick resumption of monitoring by rebinding descriptors when the file path changes, significantly improving monitoring stability.

[0029] In one possible implementation, the initial inotify event handler function in the first operating system is replaced with a preset inotify event handler function, including:

[0030] The kernel module replaces the initial inotify event handler function in the first operating system with the preset inotify event handler function.

[0031] Based on this solution, the replacement operation of the preset processing function and the initial function is encapsulated as a kernel module function, which solves the problem of strong coupling between event handling logic and kernel code in traditional solutions. Through modular design, it not only supports seamless takeover of inotify's native event stream, but also allows for flexible extension of custom processing logic (such as filtering low-risk events) through function hook mechanism, thereby enhancing the maintainability of the system while ensuring compatibility.

[0032] In one possible implementation, target file operation events and target context information for the target file are obtained through a pre-defined inotify event handler, including:

[0033] The kernel module determines whether the current file operation event is a target file operation event by using a predefined inotify event handler function;

[0034] When the current file operation event is a target file operation event, the kernel module obtains the target context information corresponding to the target file operation event;

[0035] The kernel module sends target file operation events and target context information to the kernel log.

[0036] Based on this solution, target file operation events can be accurately captured. Compared with the traditional inotify coarse-grained monitoring based on path matching, this solution binds file handles to descriptors, so that events can still be accurately associated even if the file path changes dynamically, avoiding the problem of missed reports due to path failure. At the same time, event filtering reduces invalid log output and lowers storage and analysis costs.

[0037] In one possible implementation, the kernel module determines whether the current file operation event is a target file operation event by using a pre-defined inotify event handler function, including:

[0038] When the kernel module obtains the current file operation event through the preset inotify event handling function, the kernel module determines whether the current operation event has a first notification corresponding to the descriptor;

[0039] If the kernel module determines that the current operation event has a first notification, the kernel module determines that the current operation event is associated with the inotify instance;

[0040] When the current operation event is associated with an inotify instance, the kernel module determines that the current file operation event is the target file operation event.

[0041] Based on this solution, the problem of false triggering of traditional inotify events is solved by using a dual verification mechanism based on notification identifiers and instance association. By verifying the correspondence between the event source and the target instance, it ensures that only real and valid target file operation events are recorded, further improving log accuracy in high-concurrency scenarios; at the same time, by directly manipulating the event stream through kernel modules, the performance bottleneck of user-space tools parsing logs is avoided.

[0042] Secondly, embodiments of this application also provide an electronic device, including: one or more processors; and a memory configured to store one or more programs; wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in the first aspect above.

[0043] Thirdly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in the first aspect.

[0044] Fourthly, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in the first aspect. Attached Figure Description

[0045] Figure 1 A schematic diagram of the software structure of the electronic device provided in the embodiments of this application;

[0046] Figure 2 Flowcharts of file monitoring methods provided in some embodiments of this application;

[0047] Figure 3 This is a schematic diagram of step S300 in the file monitoring method provided in some embodiments of this application;

[0048] Figure 4 Flowcharts of file monitoring methods provided in other embodiments of this application;

[0049] Figure 5 Flowcharts of file monitoring methods provided in some embodiments of this application;

[0050] Figure 6 A sub-flowchart of step S200 in the file monitoring method provided in some embodiments of this application;

[0051] Figure 7 A sub-flowchart of step S400 in the file monitoring method provided in some embodiments of this application;

[0052] Figure 8 A processing logic diagram of step S400 in the file monitoring method provided in some embodiments of this application;

[0053] Figure 9 A sub-flowchart of step S410 in the file monitoring method provided in some embodiments of this application;

[0054] Figure 10 A processing logic diagram of step S410 in the file monitoring method provided in some embodiments of this application;

[0055] Figure 11 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0056] The terms "first," "second," and "third," etc., used in this application specification, claims, and drawings are used to distinguish different objects, not to limit a specific order.

[0057] In the embodiments of this application, the words "exemplary" or "for example" are used to indicate that something is being presented as an example, illustration, or explanation. The use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0058] Before introducing the technical solutions of the embodiments of this application, the terminology involved in the embodiments of this application will be introduced by way of example.

[0059] Linux inotify mechanism: inotify is a mechanism in the Linux system used to monitor changes to the file system. Inotify can provide real-time notifications to determine when the file system reads, writes, or executes a file.

[0060] Kernel hot patch: A kernel hot patch is a technique that updates the kernel code while the system is running. By using kernel hot patches, system reboots can be avoided, reducing system downtime.

[0061] kprobe: kprobe is a feature in the Linux kernel that allows setting breakpoints on any execution path and executing custom handler functions at those breakpoints. Kprobe allows for dynamic modification of kernel code.

[0062] File operation context information: File operation context information refers to the relevant information when a file operation occurs, including user information, process information, and time information of the user performing the file operation.

[0063] Kernel log: The kernel log is a mechanism in Linux systems for recording system activities and events. By viewing the kernel log, you can understand the system's running status and locate and resolve problems.

[0064] This application provides a file monitoring method that can be applied to electronic devices.

[0065] In this application, electronic devices include, but are not limited to, mobile phones, tablets, personal computers, personal digital assistants (PDAs), workstations, large-screen devices (e.g., smart screens, smart TVs), wearable devices (e.g., smart bracelets, smartwatches), handheld game consoles, home game consoles, virtual reality (VR) devices, augmented reality (AR) devices, mixed reality devices, and in-vehicle smart terminals. This application does not limit the specific technologies or device forms used in the electronic devices. The electronic devices involved in this application run on a Linux system.

[0066] The software system of electronic devices can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses a layered Linux system as an example to illustrate the software structure of an electronic device.

[0067] Figure 1 This is a schematic diagram of the software structure of the electronic device provided in the embodiments of this application.

[0068] like Figure 1 As shown, in some examples, the software layer of a Linux system includes a user space layer and a kernel space layer, which establish an interaction channel through system call interfaces.

[0069] The user space layer may include applications, such as browsers, text editors, databases, and other software that users can directly use; in this embodiment, applications may also include files and applications that users can directly manipulate. The user space layer is the runtime environment for users and applications, and depends on services provided by the kernel.

[0070] The kernel space layer can include: the base kernel, extended kernels, the hardware abstraction layer (HAL), and various drivers. The kernel space layer directly manages hardware resources through the kernel, providing secure and efficient resource access services, and has a controllable interface to the outside world.

[0071] The basic kernel can implement core functions such as memory management, task management, interprocess communication, and interrupt management based on memory (Mem) interface, task (Task) interface, interprocess communication (IPC) interface, and interrupt interface.

[0072] The Hardware Abstraction Layer (HAL) can abstract the hardware operation interface, encapsulating the underlying driver interface into a unified application programming interface (API). This simplifies the complexity of application programs operating on the hardware.

[0073] The driver program should include at least the display driver, camera driver, audio driver, and sensor driver.

[0074] The file monitoring method provided in this application can be implemented in an electronic device with the above-described software structure.

[0075] See Figure 2 Here is a flowchart of a file monitoring method provided in some embodiments of this application;

[0076] This application provides a file monitoring method applied to an electronic device. The electronic device is equipped with a first operating system; for example, the first operating system may be a Linux operating system. See [link to relevant documentation]. Figure 2 The methods include:

[0077] S300: During the operation of the first operating system, the kernel code is modified to replace the initial inotify event handler function in the kernel with the preset inotify event handler function. The initial inotify event handler function cannot obtain the target file operation events and target context information corresponding to the target file.

[0078] In this embodiment, the initial inotify event handler function refers to the system's default event handler function. Although it can respond to file or directory operation events, its logs lack target context information and it does not monitor all necessary operations. In other words, the initial inotify event handler function cannot obtain the target file operation events and target context information of the target file. Therefore, it needs to be replaced by a preset inotify event handler function. The replaced preset inotify event handler function captures operation events in place of the original initial inotify event handler function, enabling complete acquisition of the specified file, operation events, and context information.

[0079] In some examples, various mechanisms can be used to dynamically modify the kernel code during system operation to achieve the technical effect of replacing the inotify event handler function. Several feasible methods are illustrated below. It should be noted that the following examples should not be regarded as limitations on specific mechanisms.

[0080] See Figure 3 This is a schematic diagram of step S300 in the file monitoring method provided in some embodiments of this application;

[0081] See some examples. Figure 3 During the initial operating system runtime, the kernel code is modified to replace the initial inotify event handler function in the kernel module with a preset inotify event handler function, including:

[0082] S301: During the operation of the first operating system, the kernel code is modified based on kernel hot patches or kernel probes to replace the initial inotify event handler function in the kernel module with the preset inotify event handler function.

[0083] In some examples, when using kernel hot patching to replace the initial inotify event handler function in the Linux operating system with a preset inotify event handler function, this is achieved by directly replacing the function code or modifying the instruction jump address. Specifically, firstly, a patch module containing the preset inotify event handler function can be compiled and a symbol with the same name as the initial inotify event handler function can be exported. Then, dynamic loading is achieved using system calls. During the loading process, the hot patching mechanism can use techniques such as ftrace to find the entry address of the initial inotify event handler function and directly modify the code at that address or modify the address to jump to the address of the preset inotify event handler function (completing function pointer replacement). In this way, when an inotify event is triggered subsequently, the new handler function will be executed. Using kernel hot patching can verify symbol consistency and code compatibility to ensure that the parameter list, return type, etc., of the inotify event handler function before and after the replacement match. At the same time, a function call tracing mechanism can be established to record the timestamp of each replacement, the function address before and after the replacement, and context information, and store them in a dedicated buffer.

[0084] In some examples, when using the kernel probe `kprobe` to replace the initial `inotify` event handler function in the Linux operating system with a preset `inotify` event handler function, this is achieved by setting breakpoints at specified locations. Specifically, when an `inotify` event occurs and the initial `inotify` event handler function is called, the `kprobe` is triggered, pausing the execution of the initial `inotify` handler function and instead executing the preset `inotify` event handler function. After the preset `inotify` event handler function completes its execution, the remaining parts of the initial `inotify` event handler function can be skipped, or execution can be resumed as needed. Using the kernel probe `kprobe` allows for real-time capture of function address change events by setting probes in critical kernel functions, and execution is performed by updating the internally maintained function jump table through callback functions.

[0085] In some examples, the choice between kernel hot patching or kernel probe kprobe can be based on different scenario requirements. Both methods can modify or redirect kernel code at runtime, but the specific implementation methods are different. For example, when the system load is low, the kernel hot patching method can be used to execute step S300, while when the system load is high, the kernel probe kprobe method can be used to execute step S300, thereby achieving dynamic resource optimization.

[0086] See Figure 2After the preset inotify event handler function is obtained through replacement, step S400 continues.

[0087] S400: Obtain target file operation events and target context information for the target file through a preset inotify event handler function; wherein, the target file operation events and target context information are determined by the preset inotify event handler function based on a preset first configuration file; the first configuration file is used to record at least one of the target files;

[0088] In this embodiment, the initial inotify event handling function in the first operating system is replaced with a preset inotify event handling function so that the target file operation event and target context information can be obtained through the preset inotify event handling function during the operation of the first operating system.

[0089] In some examples, target file operation events can include a variety of different types, including but not limited to at least one operation such as file creation, deletion, modification, movement, reading, or execution. For example, when a file is created, the system can generate a file creation operation record based on the action of creating the file; when a file is deleted, a corresponding file deletion operation record will be generated; if the actual content of the file is changed, or the file storage location is moved, these operations can also be tracked and recorded by the system; in addition, file reading operations, i.e., users or programs viewing the file content, and file execution operations, can also be tracked and recorded by the system.

[0090] In some examples, the target context information may include, but is not limited to, user information for performing the file operation, such as the user's ID, username, or department; process information, such as the process ID, process name, and the parent process ID that started the process; a timestamp to record the specific time the file operation occurred, which can be accurate to seconds or milliseconds; and the specific type of file operation, which may include file creation, reading, writing, modification, deletion, or moving.

[0091] Furthermore, the file monitoring method provided in this application embodiment also supports flexible configuration and expansion. For example, the target file or file directory to be monitored, as well as the file operation types and context information to be recorded, can be re-specified by modifying the first configuration file. Simultaneously, the preset inotify event handling function can also be customized and expanded according to actual needs to support more file operation types and context information collection requirements.

[0092] S500: Records target file operation events and target context information in the kernel log.

[0093] In this embodiment, to ensure the accuracy and completeness of monitoring, whenever the preset inotify event handler captures a target file operation event, it can automatically organize the event details and related context information into standardized log entries and write them to the kernel log in real time. These log entries may include the target file name, path, operation type (such as creation, deletion, modification, or move), operation timestamp, user ID of the user performing the operation, process ID, and any other relevant system or environment information.

[0094] In some examples, system administrators can check these logs regularly or as needed to track file change history, identify potential security threats or misconduct, and take appropriate action to respond.

[0095] In some examples, system administrators may also proactively access relevant logs to obtain full process information of the target file in response to functional requirements, such as security audits, compliance checks, and abnormal behavior tracking.

[0096] In some examples, to further improve the efficiency and flexibility of file monitoring, log query and retrieval functions can be provided based on the embodiments of this application. For example, system administrators can quickly filter relevant log entries based on specific query conditions, such as file name, operation type, time range, user ID, etc. This not only helps to quickly locate specific files or specific operation events, but also greatly saves administrators' time and effort, and improves work efficiency.

[0097] In this embodiment, considering the security and privacy protection of log data, all data recorded in the kernel log can be encrypted and stored in a protected storage area. Only authorized system administrators can access this log data, ensuring the confidentiality and integrity of the data. Furthermore, to prevent log data from being tampered with or deleted, the system can also set up a backup and recovery mechanism for log data, ensuring that complete file operation records are retained under any circumstances.

[0098] See Figure 4 The flowchart below shows a file monitoring method provided in other embodiments of this application.

[0099] See some examples. Figure 4 Before step S300, the document monitoring method provided in this application may further include:

[0100] S100: In response to the running of the first operating system, load the kernel module, which includes a pre-defined inotify event handler function;

[0101] In this embodiment, the kernel module, as a core component of the Linux operating system, can dynamically load code snippets into the kernel, enabling the extension or modification of kernel functionality without restarting the system. The dynamic nature and low-level access capabilities of the kernel module allow the file monitoring method provided in this embodiment to bypass the configuration complexity of traditional tools and directly achieve efficient and accurate event capture in kernel mode.

[0102] In some examples, kernel modules can be generated from compiled source code before loading, thereby extending functionality. Kernel modules can be dynamically loaded and unloaded during kernel runtime without requiring a system restart.

[0103] In some examples, when compiling a kernel module, developers can use a kernel-provided build system (such as a Makefile) to specify source code files, compilation options, and target module names. The build system parses these instructions and calls the appropriate compiler and linker toolchain to convert the source code into a kernel module. This process involves multiple stages, including preprocessing, compilation, assembly, and linking, ultimately generating a file that can be loaded by the kernel, such as a kernel object (.ko) file.

[0104] See Figure 5 The flowchart below shows a file monitoring method provided in some embodiments of this application.

[0105] In this application's embodiments, the method of loading kernel modules is not limited to one. For example, kernel modules can be loaded using the insmod or modprobe commands. Therefore, in some examples, see [link to relevant documentation]. Figure 5 Step S100 may further include:

[0106] S110: In response to the first operating system running, invoke the insmod command, or invoke the modprobe command to load the kernel module into the kernel.

[0107] In this embodiment, kernel modules can be loaded using two different commands, one of which is the `insmod` command, a manual loading method. Using the `insmod` command, users can directly load compiled kernel module files into the running Linux kernel, thereby extending kernel functionality. This process requires the user to explicitly specify the path to the kernel module file and ensure compatibility between the kernel module file and the current kernel version.

[0108] In contrast, using the `modprobe` command is a more intelligent and automated approach. During the loading process, it not only loads the specified kernel modules but also automatically handles dependencies between modules. When loading a kernel module, the `modprobe` command can automatically detect whether the module depends on other modules and load those dependent modules as needed.

[0109] In this embodiment, by selecting to use the insmod command or the modprobe command to load the kernel module, the monitoring strategy can be flexibly adjusted according to the Linux operating system's operating environment, thereby improving the overall system performance and user experience.

[0110] In this embodiment, the loaded kernel module includes a preset inotify event handler function. This preset inotify event handler function dynamically replaces the original inotify event handler function (defined herein as the initial inotify event handler function). The replaced preset inotify event handler function then captures specific operation events and related information for a specific file (defined herein as the target file). When the specific file to be monitored undergoes operations such as creation, deletion, modification, or movement, the preset inotify event handler function responds immediately, recording the corresponding operation's time information (timestamp), user information, process information, and other contextual information. This ensures that all critical operations of the target file can be captured and recorded promptly, accurately reconstructing the entire event process during problem localization and troubleshooting, thereby improving system maintainability and security.

[0111] See Figure 4 After the kernel module is loaded, the file monitoring method provided in this application embodiment further includes:

[0112] S200: Reads the first configuration file based on the kernel module;

[0113] In some examples, the first configuration file can specify all files in the file directory to be monitored, or a specific file can be specified as the target file, such as excluding temporary files in the file directory.

[0114] In some examples, the target file in the first configuration file may be in the form of a single file or in the form of a directory list consisting of file names.

[0115] In some examples, a dynamic reload mechanism is supported when configuring the primary configuration file. When the file changes, inotify's own mechanism detects the change and automatically triggers the reload process without restarting the service. Specifically, when the primary configuration file itself changes, or when the target file items, directory lists, etc., recorded in the primary configuration file change, the system can automatically reload the new configuration without stopping or restarting the entire monitoring service. For example, when the Linux system starts, the primary configuration file can be loaded into memory. At the same time, the inotify mechanism is used to set monitoring points for the primary configuration file itself. In this way, any modification to the configuration file will be detected by inotify. When the primary configuration file changes, for example, if the administrator adds a new monitoring directory, the inotify mechanism will automatically detect this change and then automatically start the reload process to ensure that the configured primary configuration file is adapted to the current target files.

[0116] As can be seen from the embodiments of this application, the file monitoring method provided in this application achieves efficient and accurate monitoring of the file system in the Linux operating system by loading kernel modules, replacing the inotify event handling function, and capturing target file operation events and target context information. This method not only improves the security and stability of the system but also provides strong support for subsequent auditing, analysis, and troubleshooting.

[0117] See Figure 6 This is a sub-flowchart of step S200 in the file monitoring method provided in some embodiments of this application;

[0118] See some examples. Figure 6 The steps for reading the first configuration file based on the kernel module may include:

[0119] S210: Reads file information or a list of target files from the first configuration file based on the kernel module;

[0120] The file information and target file list may include attributes such as the target file's name, type, path, size, and creation or modification time.

[0121] In some examples, the first configuration file can store file information or the contents of a list of target files in a preset format, such as key-value pairs, JSON, XML, or a custom text format. When the kernel module reads the first configuration file, it can extract the required information by parsing different formats.

[0122] After reading the first configuration file, the kernel module can configure preset inotify event handling functions based on the obtained file information to clarify the monitoring rules. The monitoring rules define which files or file types should be monitored, and which operation events and context information need to be recorded.

[0123] S220: Based on the kernel module, an inotify instance corresponding to the target file is created according to the file information or the target file list, and a descriptor is set in the inotify instance, where the descriptor includes the watch descriptor.

[0124] In some examples, the watch descriptor is used to represent a monitored file or directory within the inotify mechanism. For instance, when a kernel module adds a watch item to an inotify instance using the inotify_add_watch function, it returns a watch descriptor that uniquely identifies the watch item. Through the watch descriptor, the kernel module can read event information related to that watch item.

[0125] In some examples, the descriptor can also be an inode descriptor, which is used to uniquely identify a file or directory at the file system level. In the inotify mechanism, inode descriptors can be used in conjunction with watch descriptors to provide more granular file monitoring capabilities. When the inode of a file or directory changes, such as when a file is moved or renamed, the inode descriptor helps the kernel module identify that it is a different representation of the same file or directory, thus allowing it to continue monitoring. This combined use of inode and watch descriptors enhances the flexibility and accuracy of file monitoring.

[0126] In some examples, the descriptor can also be other types of descriptors in the inotify mechanism, such as the inotify file descriptor. An inotify file descriptor can be created by calling the inotify_init function, and it represents an inotify instance. Kernel modules use this file descriptor to add or remove monitoring items to the inotify instance, and to read event information.

[0127] Furthermore, event information in the inotify mechanism can also be described using the inotify_event structure, which can contain a watch descriptor field (wd) to identify the specific monitored item that generated the event. Therefore, when reading event information, the kernel module can use the watch descriptor to associate it with the specific monitored item and file or directory.

[0128] In the embodiments of this application, by properly setting and using descriptors, the kernel module can achieve real-time monitoring and efficient processing of the file system.

[0129] In some examples, the inotify instance corresponds to various operation events that need to be monitored on the target file, such as file creation, removal, modification, or attribute changes. Once these events occur, the inotify instance can send corresponding notifications to the kernel module through a descriptor. After receiving these notifications, the kernel module will process them according to the pre-defined monitoring policy. For example, if the monitoring policy stipulates that all changes to the target file should be recorded, the kernel module will record detailed information about these operations. Through this method, the embodiments of this application can achieve real-time and efficient monitoring of the target file, ensuring the security and integrity of the file.

[0130] In some examples, the initial inotify event handler in the first operating system is replaced with a preset inotify event handler, including:

[0131] The kernel module replaces the initial inotify event handler function in the first operating system with the default inotify event handler function.

[0132] In the Linux operating system, kernel modules can monitor and manage critical events during system operation by replacing the original inotify event handlers. Specifically, the kernel module replaces the initial inotify event handler in the primary operating system with a pre-defined inotify event handler. This replacement allows the system to effectively acquire and process target file operation events at runtime through the pre-defined inotify event handler. These events include not only basic operations such as file creation, modification, and deletion, but also contextual information related to the target file. Contextual information can include detailed data such as file path, type, and permissions, which is extremely important for system security, performance monitoring, and logging. In this way, the kernel module can provide the primary operating system with more accurate and efficient event handling capabilities, thereby enhancing the overall performance and security of the system.

[0133] See Figure 7 This is a sub-flowchart of step S400 in the file monitoring method provided in some embodiments of this application; see also Figure 8 This is a processing logic diagram of step S400 in the file monitoring method provided in some embodiments of this application;

[0134] See some examples. Figure 7 and Figure 8During the operation of the first operating system, the steps for obtaining target file operation events and target context information for the target file through the preset inotify event handling function include:

[0135] S410: During the operation of the first operating system, the kernel module determines whether the current file operation event is a target file operation event by using the preset inotify event handling function;

[0136] In this embodiment, the current file operation events captured by the kernel module through the preset inotify event handling function include target file operation events, operation events generated by performing operations on other files (non-target files), and other events that do not need to be monitored when performing operations on the target file. Therefore, it is necessary to use the preset inotify event handling function to determine whether the current file operation event is a target file operation event in order to further execute subsequent logging steps.

[0137] S420: When the current file operation event is a target file operation event, the kernel module obtains the target context information corresponding to the target file operation event;

[0138] S430: The kernel module sends target file operation events and target context information to the kernel log to record target file operation events and target context information in the kernel log.

[0139] In this embodiment, by pre-setting the inotify event handling function, the kernel module can accurately identify target file operation events. Once the current file operation event is determined to be a target file operation event that needs to be monitored, the kernel module will immediately obtain the target context information related to the event. This information not only covers the basic attributes of the target file, such as file path, type, and permissions, but can also include more detailed operation details, such as operation time, operation type (e.g., creation, modification, deletion), and file state before and after the operation. This information is of great value for subsequent security auditing, performance analysis, and abnormal behavior detection.

[0140] After obtaining target file operation events and target context information, the kernel module sends this information to the kernel log for recording. As a crucial information recording tool for system runtime, the kernel log can be stored long-term and provided for subsequent querying and analysis. By recording target file operation events and target context information, the kernel log provides system administrators with rich monitoring data and audit clues, helping to promptly identify and address potential security threats or performance bottlenecks.

[0141] In some examples, if the current file operation event is not the target file operation event, the kernel module can ignore the current file operation event and not continue to execute steps S420-S430, thereby reducing unnecessary system resource consumption and improving the overall efficiency of the file monitoring method.

[0142] In some examples, to improve the real-time performance and response speed of file monitoring, kernel modules can also employ asynchronous notification mechanisms. When the default inotify event handler detects a target file operation event, it immediately triggers an asynchronous notification, informing the kernel module of the event information without waiting for the event processing to complete. Upon receiving the asynchronous notification, the kernel module can respond quickly and begin acquiring the target file operation event and target context information. This asynchronous processing method can further reduce event processing latency and improve the system's real-time performance and response speed.

[0143] See Figure 9 This is a sub-flowchart of step S410 in the file monitoring method provided in some embodiments of this application; see also Figure 10 This is a processing logic diagram of step S410 in the file monitoring method provided in some embodiments of this application.

[0144] See some examples. Figure 9 and Figure 10 The kernel module determines whether the current file operation event is a target file operation event through the preset inotify event handler function by following these steps:

[0145] S411: When the kernel module obtains the current file operation event through the preset inotify event handler function, the kernel module determines whether the current operation event has a first notification corresponding to the descriptor; the first notification is used to identify whether the operation event is associated with the target file. In the inotify mechanism of the Linux operating system, each monitored file or directory can be associated with a specific descriptor. When an operation occurs on a file or directory, the inotify mechanism generates an event notification containing descriptor information related to the operation event. By comparing the descriptor in the event notification with the preset target file descriptor, the kernel module can determine whether the current operation event is an operation performed on the target file.

[0146] S412: If the kernel module determines that the current operation event has a first notification, it determines that the current operation event is associated with the inotify instance. If the current operation event has a first notification corresponding to a descriptor (i.e., the descriptor in the event notification matches the preset target file descriptor), then the kernel module considers the current operation event to be a target file operation event and requires further processing. Conversely, if the current operation event does not have a first notification corresponding to a descriptor, or if other notifications are generated (i.e., the descriptor in the event notification does not match the preset target file descriptor), then the kernel module considers the current operation event not to be a target file operation event and can choose to ignore the event or perform other processing.

[0147] S413: When the current operation event is associated with an inotify instance, the kernel module determines that the current file operation event is the target file operation event.

[0148] The kernel module, through the methods provided in this application embodiment, can accurately capture and identify target file operation events, providing reliable data support for subsequent security auditing, performance analysis, and abnormal behavior detection. Furthermore, since this process is implemented at the kernel level, it is highly efficient and real-time, ensuring that the system's monitoring capabilities for file operations remain optimal at all times.

[0149] It should be noted that the solutions in this application, besides being applied to technical scenarios such as security auditing, compliance checks, and tracking abnormal behavior, should be considered applicable to any other scenario requiring monitoring of file operations. For example, in a data center environment, system administrators need to manage and maintain a large number of servers. The solutions in this application can also be used for file operations on these servers, making it easier for system administrators to detect and handle potential problems promptly. Furthermore, cloud service providers need to ensure the security and privacy of customer data. When a user performs any file operation on a cloud server, detailed records of specific operations performed on specific files can help prevent data leaks or other security issues. Additionally, in industries such as finance and healthcare, enterprises need to comply with strict data management and protection regulations. Recording detailed information on operations on all sensitive data helps meet regulatory compliance requirements.

[0150] The file monitoring method provided in this application dynamically replaces the inotify event handling function and adds context information for file operations, ensuring timely capture of critical file operations. This allows electronic devices to accurately reconstruct the entire event process during problem localization and troubleshooting, thereby significantly improving system maintainability.

[0151] Figure 11This is a schematic diagram of an electronic device provided in an embodiment of this application.

[0152] like Figure 11 As shown, the electronic device may include devices such as servers and terminals; the electronic device includes one or more processors 101 and a memory 102. The memory 102 is configured to store one or more programs. When the one or more programs are executed by the one or more processors 101, the one or more processors 101 implement the file monitoring method described in the above embodiments.

[0153] See also Figure 11 The electronic device 100 may also include a communication interface 103 and a communication bus 104.

[0154] The processor 101, memory 102, and communication interface 103 communicate with each other via communication bus 104. Communication interface 103 is used to communicate with other network elements such as clients or other servers.

[0155] In some embodiments, one or more processors 101 are used to execute one or more programs 105, specifically performing the relevant steps in the above-described file monitoring method embodiments. Specifically, program 105 may include program code, which includes computer-executable instructions.

[0156] For example, processor 101 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Electronic device 100 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.

[0157] In some embodiments, memory 102 is used to store one or more programs 105. Memory 102 may include high-speed RAM memory and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0158] Specifically, program 105 can be called by processor 101 to cause electronic device 100 to execute the steps in the file monitoring method.

[0159] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on an electronic device 100, causes the electronic device 100 to perform the file monitoring method described above.

[0160] The executable instructions can be used to cause the electronic device 100 to perform file monitoring method operations.

[0161] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0162] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects of the corresponding file monitoring method provided above, and will not be repeated here.

[0163] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0164] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0165] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0166] For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0167] More specific examples (a non-exhaustive list) of computer-readable media include the following: electrical connections having one or more wires (electronic devices), portable computer disks (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0168] Furthermore, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory. It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof.

[0169] In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0170] The above embodiments are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A file monitoring method characterized by, Applied to electronic devices, the method includes: In response to the running of the first operating system, the kernel module is loaded into the kernel; During the operation of the first operating system, the kernel code is modified based on kernel hot patches or kernel probes to replace the initial inotify event handling function in the kernel module with a preset inotify event handling function; The kernel module reads the first configuration file, loads the first configuration file into memory, and sets monitoring points for the first configuration file based on the inotify mechanism; The kernel module obtains target file operation events and target context information for the target file through the preset inotify event handling function; wherein, the target file operation events and the target context information are determined by the preset inotify event handling function based on a preset first configuration file, the first configuration file being used to record at least one of the target files; Based on the preset inotify event handling function, the target file operation event and the target context information are recorded in the kernel log.

2. The file monitoring method according to claim 1, characterized in that, The target context information includes at least one of the following: user information for executing the target file operation event, process information for executing the target file operation event, and time information for executing the target file operation event.

3. The file monitoring method according to claim 1, characterized by, The kernel module is generated based on compiled source code; The step of loading the kernel module into the kernel in response to the operation of the first operating system includes: In response to the running of the first operating system, the insmod command or the modprobe command is invoked to load the kernel module into the kernel.

4. The file monitoring method according to claim 1, characterized by, The step of reading the first configuration file based on the kernel module, loading the first configuration file into memory, and setting monitoring points for the first configuration file based on the inotify mechanism includes: The kernel module reads the file information or list of target files from the first configuration file and sets the monitoring points in the first configuration file based on the inotify mechanism.

5. The file monitoring method according to claim 4, characterized by, After reading the first configuration file based on the kernel module, loading the first configuration file into memory, and setting the monitoring points on the first configuration file based on the inotify mechanism, the method further includes: Based on the kernel module, an inotify instance corresponding to the target file is created according to the file information or the target file list, and a descriptor is set in the inotify instance, wherein the descriptor includes a watch descriptor.

6. The file monitoring method according to claim 5, characterized by, The step of obtaining the target file operation events and target context information for the target file through the preset inotify event handling function includes: The kernel module determines whether the current file operation event is the target file operation event through the preset inotify event handling function; When the current file operation event is the target file operation event, the kernel module obtains the target context information corresponding to the target file operation event; The kernel module sends the target file operation events and the target context information to the kernel log.

7. The file monitoring method according to claim 6, characterized by, The kernel module determines whether the current file operation event is the target file operation event through the preset inotify event handling function, including: When the kernel module obtains the current file operation event through the preset inotify event handling function, the kernel module determines whether the current file operation event has a first notification corresponding to the descriptor; If the kernel module determines that the current file operation event has the first notification, the kernel module determines that the current file operation event is associated with the inotify instance; When the current file operation event is associated with the inotify instance, the kernel module determines that the current file operation event is the target file operation event.

8. An electronic device, comprising: include: One or more processors; as well as, The memory is configured to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the file monitoring method according to any one of claims 1-7.

Images