Access control method and apparatus, electronic device, storage medium, and product

Abstract

A method and device for access control, an electronic device, a storage medium and a product are disclosed. The method comprises: in the case where an access request for a target file is detected, obtaining an access path corresponding to the access request, and obtaining an authoritative path in an extended attribute of the target file; and determining whether to allow an operation requested by the access request according to an access control rule, a subject attribute of the access request, an access type of the access request, and a consistency relationship between the access path and the authoritative path, wherein the access control rule is used to describe an operation type allowed when a preset subject path accesses a preset object path or the authoritative path. The present application solves the technical problems of inconsistent access control strategies, invalid identity binding, and the like, which are caused by the fact that a same file object can correspond to multiple different paths and a related path-based access control method only relies on a transient path of a file at an access moment for permission matching.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and more specifically, to an access control method, apparatus, electronic device, storage medium, and product. Background Technology

[0002] Enforced access control is a core mechanism for operating system security, with mainstream solutions including label-based (such as SELinux) and path-based (such as AppArmor). While label-based solutions offer stability in object identity, they suffer from abstract policies and high maintenance costs. Path-based solutions, which use file paths as the basis for rules, are intuitive, easy to understand, and easy to maintain, but they have inherent drawbacks.

[0003] In the Linux file system, a path is merely an external name for a file object, not a unique and stable identifier. The same file object can correspond to multiple different paths through hard links, bind mounts, renaming, or multiple namespace views. Related path-based access control methods rely solely on the instantaneous path at the moment of access for permission matching. This leads to technical problems such as inconsistent access control policies, invalid identity binding, and vulnerability to attacks that allow attackers to bypass security restrictions, since the same file object may correspond to multiple different paths. For example, attackers can use path aliases or "delete first, then create" techniques to allow controlled files to be accessed through unauthorized paths, thereby circumventing security policies.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides an access control method, apparatus, electronic device, storage medium, and product to at least solve the technical problems caused by inconsistent access control policies, invalid identity binding, and vulnerability to attacks by attackers to bypass security restrictions, since the same file object may correspond to multiple different paths and related path-based access control methods only rely on the instantaneous path of the file at the time of access for permission matching.

[0006] According to one aspect of this application, an access control method is provided, comprising: upon detecting an access request for a target file, obtaining the access path corresponding to the access request, and obtaining the authoritative path in the extended attributes of the target file, wherein the authoritative path is a baseline path pre-bound to the target file and independent of the actual access path of the target file, used to characterize the legal path for which the target file is authorized to be accessed; determining whether to allow the operation requested by the access request based on the consistency relationship between the access control rules, the subject attribute of the access request, the access type of the access request, the access path, and the authoritative path, wherein the access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or an authoritative path.

[0007] Optionally, the authoritative path is bound to the extended attributes of the target file through the following steps: normalizing the absolute path of the target file to obtain a normalized path; detecting whether the target file exists and whether the extended attributes of the target file contain an authoritative path attribute for storing the authoritative path; if the target file exists and the extended attributes of the target file do not contain an authoritative path attribute, creating the authoritative path attribute and writing the normalized path as the authoritative path into the authoritative path attribute; if the target file does not exist, obtaining the pre-binding carrier corresponding to the target file, wherein the pre-binding carrier is a placeholder object pre-established before the target file is actually created to carry the authoritative path; writing the normalized path as the authoritative path into the extended attributes or pending attribute record corresponding to the pre-binding carrier; after obtaining the pre-binding carrier, detecting whether the process performs a target operation on the target file, wherein the target operation is an operation that triggers the allocation or reuse of the target file's inode; if a target operation is detected, associating the authoritative path in the pre-binding carrier with the extended attributes of the target file during the inode allocation or reuse phase.

[0008] Optionally, the absolute path of the target file is normalized to obtain a normalized path, including: performing at least one of the following processes on the absolute path of the target file to obtain a normalized path: merging consecutive path separators in the absolute path of the target file into a single path separator; eliminating the current directory component in the absolute path of the target file, and eliminating the resolvable parent directory component in the absolute path of the target file, wherein the current directory component represents the path component in the absolute path that refers to the current directory and does not change the actual target of the absolute path, and the parent directory component represents the path component in the absolute path that refers to the previous directory and is used to trace the absolute path back one level; unifying the directory separators in the absolute path of the target file to a preset separator format; performing normalized mapping on the absolute path of the target file based on the controlled root directory or system root path; and converting the absolute path of the target file into a globally consistent path representation based on mount view information, wherein the mount view information is information representing the file system mount relationship.

[0009] Optionally, the method further includes: during the allocation or reuse phase of an index node, if the same index node corresponds to multiple path entries, the path entry that serves as the authoritative path is determined in the following order: if the authoritative path attribute in the extended attributes of the target file corresponding to the index node has already registered an authoritative path, the registered authoritative path is used as the authoritative path; if the authoritative path attribute in the extended attributes of the target file has not registered an authoritative path, the normalized path that was successfully written to the authoritative path attribute when the target file was first managed is used as the authoritative path; if two or more path entries simultaneously request to serve as authoritative paths, the path entry with higher priority in the access control rules is used as the authoritative path; if the authoritative path cannot be uniquely determined, the target file is determined to be in a path identity conflict state, the operation requested by the access request for the target file is rejected, and the path identity conflict state is audited and recorded, wherein the path identity conflict state is the state in which the path entry that cannot be uniquely determined as the authoritative path among the multiple path entries corresponding to the same index node.

[0010] Optionally, the method further includes: upon receiving a deletion request for a target file, detecting whether an authoritative path attribute exists in the extended attributes of the target file; if the authoritative path attribute does not exist in the extended attributes of the target file, deleting the target file according to a preset deletion process; if the authoritative path attribute exists in the extended attributes of the target file, retaining the pre-bound carrier corresponding to the authoritative path of the target file and retaining the authoritative path attribute, wherein retaining the pre-bound carrier includes any of the following methods: blocking the physical deletion of the target file; converting the target file into an empty content object before the deletion transaction corresponding to the deletion request is committed; after the target file is deleted, re-establishing the pre-bound carrier in the original path of the target file and restoring the authoritative path attribute.

[0011] Optionally, based on the consistency relationship between the access control rules, the subject attributes of the access request, the access type of the access request, and the access path with the authoritative path, it is determined whether the operation requested by the access request is allowed. This includes: detecting whether there is a path identity conflict in the target file, wherein a path identity conflict is when there are two or more conflicting authoritative paths corresponding to the same inode, or an authoritative path is missing and defined as abnormal by the access control rules; if there is no path identity conflict in the target file, detecting whether the authoritative path in the extended attributes of the target file is consistent with the controlled path declared by the access control rules; if the authoritative path and the controlled path are consistent, detecting whether the access path belongs to the authorized access entry corresponding to the authoritative path, wherein the authorized access entry includes at least one of the authoritative path itself and the controlled alias entry allowed by the access control rules; if the access path belongs to the authorized access entry, determining whether the subject attributes and access type both meet the operation permissions for the authoritative path according to the access control rules; if the subject attributes and access type both meet the operation permissions for the authoritative path, allowing the operation requested by the access request.

[0012] Optionally, the method further includes: processing the access request according to a preset processing mode when the authoritative path does not exist in the extended attributes of the target file, wherein the preset processing mode is any one of default denial, default audit only, and compatibility allow; recording the judgment result of whether to allow the operation requested by the access request, wherein, when the access path is inconsistent with the authoritative path, the access path, the authoritative path, and the audit event of the inconsistency between the access path and the authoritative path are recorded; when the authoritative path is inconsistent with the controlled path, the operation requested by the access request is denied; when the access path does not belong to the authorized access entry point, the operation requested by the access request is denied; when the subject attribute and / or access type do not meet the operation permissions for the authoritative path, the operation requested by the access request is denied.

[0013] Optionally, based on the consistency relationship between the access control rules, the subject attributes of the access request, the access type of the access request, and the access path with the authoritative path, it is determined whether the operation requested by the access request is allowed. This includes: obtaining the priority mode in the access control rules, wherein the access control rules declare a controlled path, and the controlled path is the path identity declared by the access control rules and managed by the access control rules; the authoritative path corresponds to an authorized access entry, and the authorized access entry includes at least one of the authoritative path itself and the controlled alias entry allowed by the access control rules; if the priority mode indicates the first priority mode, and if the authoritative path is consistent with the controlled path, the access path belongs to an authorized access entry, and the subject attributes and access type meet the operation permissions for the authoritative path defined by the access control rules, the operation requested by the access request is allowed; otherwise, the operation requested by the access request is denied; if the priority mode indicates the second priority mode, and if the authoritative path is missing, or the access path is inconsistent with the authoritative path, the operation requested by the access request is allowed after auditing the access request.

[0014] Optionally, the method further includes: when the priority mode indicates the third priority mode, if the access path is inconsistent with the authoritative path, after rejecting the operation requested by the access request, performing at least one of controlled relocation and alias registration on the access request; wherein, controlled relocation is the process of redirecting the access request to the authorized path under controlled conditions, and alias registration is the process of registering the access path as a controlled alias entry of the authoritative path; when the priority mode indicates the fourth priority mode, if the trusted subject meets the preset additional constraints, allowing the trusted subject to perform path identity restoration; wherein, the trusted subject is the subject granted governance permissions by the access control rules, and path identity restoration is the process of correcting the authoritative path of the target file.

[0015] Optionally, the method further includes: when the access request is a path migration operation, processing the directory entry movement of the target file and the update of the authoritative path in the extended attributes of the target file as the same transaction, wherein the path migration operation is an operation that changes the path of the target file; when the file system where the target file resides supports a transaction mechanism or a logging mechanism, executing the directory entry movement and the update of the authoritative path as the same atomic commit unit; when the file system where the target file resides does not support a transaction mechanism and does not support a logging mechanism, executing the directory entry movement and the update of the authoritative path according to a preset transaction process, so that the directory entry movement and the update of the authoritative path take effect simultaneously or neither take effect simultaneously, wherein the preset transaction process includes pre-checking the directory entry movement and the update of the authoritative path, retaining the old state, performing verification after commit, and rolling back in case of failure; when the directory entry movement succeeds but the update of the authoritative path fails, putting the target file into an abnormal protection state, wherein the abnormal protection state includes at least one of blocking the current operation from taking effect, rolling back the directory entry movement, marking the target file as mismatched and rejecting the operation requested by subsequent access requests for the target file, and only allowing trusted repair processes to process the target file.

[0016] Optionally, the method further includes: when the target file is copied, imported, or restored, performing the following processing on the target file according to the access control rules: when the access control rule indicates an inheritance policy, using the authoritative path of the source object of the target file as the authoritative path of the target file; when the access control rule indicates a rebinding policy, binding a new authoritative path to the target file; when the access control rule indicates a remanagement policy, identifying the target file as an object to be remanaged, and determining an authoritative path for the target file after it is remanaged; when the access control rule indicates a trusted binding policy and the subject of the access request is a trusted subject, allowing the trusted subject to bind an authoritative path to the target file, wherein the trusted subject is the subject granted governance permissions by the access control rule.

[0017] Optionally, the method further includes: when adding a new path entry to the target file, keeping the authoritative path in the extended attributes of the target file unchanged, wherein adding the path entry includes creating a hard link to the target file and presenting the target file through different mount points or different file system views; when initiating an access request to the target file through the newly added path entry, obtaining the access path corresponding to the access request, reading the authoritative path from the extended attributes of the target file, and determining whether to allow the operation requested by the access request based on the consistency relationship between the access path and the authoritative path.

[0018] Optionally, the method further includes: performing at least one of the following protection processes on the authoritative path attribute of the stored authoritative path: setting the authoritative path attribute as an extended attribute under a protected namespace, wherein the authoritative path attribute is identified by a preset key value; determining the modification permission of the authoritative path attribute to only processes with preset management permissions, thereby prohibiting user-mode processes from directly modifying the authoritative path attribute; auditing the setting, modification, and deletion operations of the authoritative path attribute; and attaching at least one of the following to the attribute value of the authoritative path attribute: verification information, version information, policy identifier, and integrity protection field.

[0019] According to another aspect of this application, an access control device is also provided, comprising: an acquisition module, configured to acquire, upon detecting an access request for a target file, the access path corresponding to the access request and the authoritative path in the extended attributes of the target file, wherein the authoritative path is a baseline path pre-bound to the target file and independent of the actual access path of the target file, used to characterize the legal path for which the target file is authorized to be accessed; and a judgment module, configured to determine whether the operation requested by the access request is allowed based on the consistency relationship between the access control rules, the subject attribute of the access request, the access type of the access request, the access path, and the authoritative path, wherein the access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or an authoritative path.

[0020] According to another aspect of this application, an electronic device is also provided, comprising: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes the access control method described above during runtime.

[0021] According to another aspect of this application, a non-volatile storage medium is also provided, the storage medium including a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above access control method.

[0022] According to another aspect of this application, a computer program product is also provided, comprising a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and the computer program implements the above-described access control method when executed by a processor.

[0023] In this application, upon detecting an access request for a target file, the access path corresponding to the access request is obtained, along with the authoritative path from the target file's extended attributes. The authoritative path is a baseline path pre-bound to the target file and independent of its actual access path, representing a legitimate path authorized for access to the target file. Based on the consistency between access control rules, the subject attribute of the access request, the access type of the access request, the access path, and the authoritative path, a determination is made as to whether the operation requested by the access request is allowed. The access control rules describe the types of operations allowed when a preset subject path accesses a preset object path or authoritative path, thus achieving the goal of controlling file access. The physical identity of an object is decoupled from its logical access path, and persistent object-level authoritative paths are used as the core authorization basis. At the same time, instantaneous access paths are combined for entry verification. This achieves the goal of ensuring consistent execution of access control policies for the same file object in complex scenarios such as hard links, bound mounts, renames, or multiple mounted views. It effectively blocks bypass attacks based on path aliases or path changes. This solves the technical problems caused by inconsistent access control policies, invalid identity binding, and vulnerability to attacks by attackers to bypass security restrictions, since the same file object may correspond to multiple different paths and related path-based access control methods only rely on the instantaneous path of the file at the time of access for permission matching. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0025] Figure 1 This is a flowchart of an access control method according to an embodiment of this application;

[0026] Figure 2 This is a flowchart of an authoritative path binding method according to an embodiment of this application;

[0027] Figure 3 This is a flowchart of a method for determining whether to allow an access request for an operation according to an embodiment of this application;

[0028] Figure 4 This is a flowchart of another method for determining whether to allow an access request to perform an operation, according to an embodiment of this application.

[0029] Figure 5 This is a structural diagram of an access control device according to an embodiment of this application;

[0030] Figure 6 This is a hardware structure block diagram of a computer terminal according to an embodiment of the present application for an access control method. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0034] Mandatory Access Control (MAC): An access control mechanism enforced by system security policies.

[0035] Linux Security Module (LSM): A security extension framework provided by the kernel for attaching security policy logic at critical kernel operation points.

[0036] Extended Attributes: A file system feature that associates name:value key-value pairs with the inode of a file or directory. It is often used to store access control lists and security policies.

[0037] A brief overview of the division of operating system technology fields is shown in Table 1.

[0038] Table 1

[0039]

[0040] With the increasing security requirements of operating systems, MAC (Access Control Mechanism) has become a key technical means to implement system-level constraints on the access relationship between process subjects and file objects. Related MAC technical solutions are mainly divided into two categories: security label-based and file path-based. Label-based solutions (such as SELinux and Smack) decouple object identity from access paths by directly binding security attributes to the underlying objects such as files, directories, or processes. Its core advantage is that even if a file is renamed, a directory is moved, or the path is changed, as long as the underlying object remains unchanged, its security attributes remain unchanged, thus ensuring a high degree of consistency and stability in access control results. Furthermore, this type of solution supports the construction of complex, fine-grained security models, capable of accurately describing the access relationships between different process domains and file types, making it suitable for policy design in high-security systems. However, tag-based solutions also have significant limitations: their policy definitions revolve around abstract concepts such as security context, type, domain, and role, lacking a direct mapping to physical file paths, resulting in less intuitive policy expression; at the same time, they involve complex mechanisms such as type definition, domain conversion, and Boolean switches, which increases the learning cost and maintenance difficulty for ordinary operations and maintenance personnel and developers, making it difficult to meet the intuitive management needs of organizing business resources based on directory structure.

[0041] In contrast, path-based access control schemes (such as AppArmor and TOMOYO Linux) use the specific path of the file access request as the basis for rule matching, with policy rules directly written around the file or directory path. For example, an administrator can directly define that an application is only allowed to read configuration files in a specific directory or write to a specific log path. Because the rules of this type of scheme directly correspond to the file system hierarchy, they conform to the daily cognitive habits of system administrators and operations personnel, and therefore have significant advantages in policy writing, understanding, and rapid deployment of application isolation and directory-level authorization list control. However, path-based schemes have an inherent flaw in terms of object identity stability. In the Linux file system, the path is only the external name of the file object, not the unique and stable identifier of the underlying inode. The same file object can be visible under different paths through various means such as hard links, bind mounts, overlay views, directory relocation, or changes in mount namespaces. If the control logic only relies on the instantaneous path resolved at the time of access for matching, when the same file object is accessed through multiple different paths, it is very easy to cause inconsistent control policies. Especially in container environments, multi-mounted views, or chroot isolation scenarios, view switching may weaken security restrictions; and in file renaming or migration scenarios, the original path rules may become invalid due to path changes, leading to false approval or false rejection issues.

[0042] In summary, while path-based solutions like AppArmor offer intuitive rule expression capabilities, they still have shortcomings in handling multiple path aliases, ensuring consistent object identity, and resisting bypass attacks. Related technologies still have room for improvement in balancing object binding stability with the intuitiveness of policy expression. In particular, when attackers create path aliases using hard links, binding mounts, or "delete-then-create" techniques, control mechanisms based on transient paths struggle to accurately identify the true identity of file objects, thus creating opportunities for security bypasses.

[0043] To address the aforementioned issues, this application provides relevant solutions, which are detailed below.

[0044] According to an embodiment of this application, an access control method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0045] Figure 1 This is a flowchart of an access control method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0046] Step S102: If an access request for a target file is detected, obtain the access path corresponding to the access request and obtain the authoritative path in the extended attributes of the target file. The authoritative path is a baseline path that is pre-bound to the target file and is independent of the actual access path of the target file. It is used to characterize the legitimate path for which the target file is authorized to be accessed.

[0047] In step S102, the access path corresponding to the current access request is obtained. This access path is the path string used by the process when actually accessing the file in the file system. Simultaneously, the extended attributes associated with the inode node of the target file in the file system are read, and the authoritative path stored therein is extracted. The authoritative path is a baseline path identifier pre-bound and persistently stored by the system with the target file object. It is independent of the actual access path of the target file and aims to characterize the legitimate identity path for authorized access to the file object. In this way, the core basis of access control is shifted from the transient, variable access path to the stable authoritative path bound to the underlying file object.

[0048] Step S104: Based on the access control rules, the subject attribute of the access request, the access type of the access request, and the consistency relationship between the access path and the authoritative path, determine whether the operation requested by the access request is allowed. The access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or an authoritative path.

[0049] Access control rules refer to a set of predefined access control policies stored in the system. Access control rules describe the permissions that a specific subject is allowed to perform on a specific object under certain conditions. Specifically, access control rules typically include object identifiers (such as a preset object path or object authoritative path), subject identifiers (such as a preset subject path, process identifier, or user identifier), and a list of allowed operation types. The core logic of the rules lies in establishing an authorization mapping relationship between subjects and objects; for example, defining that process A is only allowed to access the file object with the authoritative path " / etc / app / config.yaml" in read-only mode.

[0050] The subject attributes of an access request refer to the identity characteristics and security context information possessed by the executing entity (i.e., process or user) initiating the file access operation. Subject attributes include, but are not limited to: the process's user identifier, group identifier, process unique identifier, the process's security domain, the process's executable file path (i.e., the subject path), and the process's capability set. Subject attributes are primarily used to identify the subject initiating the access request, thereby determining whether the subject is qualified to access the authoritative path of a specific object and whether it meets the preset subject constraints in the access control rules.

[0051] The access type of an access request refers to the specific file system operation requested. Access types include, but are not limited to: reading (e.g., open, read system calls), writing (e.g., open with O_WRONLY, write system calls), execution (e.g., execve system call), creation (e.g., open with O_CREAT), deletion (e.g., unlink system call), renaming, linking, and attribute modification (Chmod / Chown). The access type determines the subject's specific intention to operate on the object file. It must be considered in conjunction with access control rules to determine whether the current access type falls within the list of allowed operation types authorized to the subject. For example, even if a subject is authorized to access a file, if its requested operation type is write, but the rules only allow reading, the access will be denied.

[0052] For example, in the decision-making process of step S104, the authoritative path is used as the core authorization basis to determine whether the subject in the current access request has the permission to access the object corresponding to the authoritative path, and further verify the consistency between the current access path and the authoritative path. If the current access path belongs to the authorized entry point or controlled alias corresponding to the authoritative path, and the subject attributes and access type meet the requirements of the access control rules, the access request is allowed; otherwise, if the authoritative path is missing, the authoritative path is inconsistent with the policy declaration path, or the current access path does not belong to the allowed authorized entry point, the access request is rejected. Through the decision-making mechanism based on authoritative path consistency verification, unauthorized alias access generated by techniques such as hard links, binding mounts, or path renaming can be effectively identified and blocked, ensuring that even if a file object is accessed through multiple different paths, its access control policy remains unchanged and cannot be bypassed.

[0053] The above steps involve obtaining the access path corresponding to the access request when an access request for the target file is detected, and obtaining the authoritative path in the extended attributes of the target file. The authoritative path is a baseline path that is pre-bound to the target file and is independent of the actual access path of the target file. It is used to represent the legitimate path for authorized access to the target file. Based on the consistency relationship between the access control rules, the subject attributes of the access request, the access type of the access request, the access path, and the authoritative path, it is determined whether the operation requested by the access request is allowed. The access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or authoritative path. This achieves the purpose of decoupling the physical identity of the file object from the logical access path, and using the persistent object-level authoritative path as the core authorization basis, while combining the instantaneous access path for entry verification. This achieves the technical effect of ensuring the consistent execution of the access control policy on the same file object in complex scenarios such as hard links, bound mounts, renaming, or multiple mounted views, and effectively blocking bypass attacks based on path aliases or path changes.

[0054] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0055] Figure 2 This is a flowchart of an authoritative path binding method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0056] Step S201: Normalize the absolute path of the target file to obtain a normalized path.

[0057] In step S201, the absolute path of the target file is first normalized to eliminate inconsistencies caused by differences in path representation (such as relative paths, redundant separators, symbolic link resolution, etc.), thereby obtaining a unique normalized path. Specifically, the normalization process includes converting relative paths to absolute paths, eliminating consecutive path separators, parsing and removing the current directory identifier (“.”) and the parent directory identifier (“..”), and unifying the path format under different file system views.

[0058] Step S202: Detect whether the target file exists, and detect whether the target file's extended attributes contain an authoritative path attribute for storing the authoritative path.

[0059] In step S202, it is detected whether the target file actually exists in the file system, and further checked whether the extended attributes of the file object have pre-stored the authoritative path attribute used to identify its legitimate identity. If the target file exists, the extended attribute list associated with its inode node is read to determine whether a predefined authoritative path key value (e.g., security.authoritative_path) exists. That is, if the file exists and is bound to an authoritative path, it means that the file is under control; if the file exists but is not bound, immediate binding needs to be performed; if the file does not exist, the pre-binding process needs to be performed.

[0060] Step S203: If the target file exists and the authoritative path attribute does not exist in the extended attributes of the target file, create the authoritative path attribute and write the normalized path as the authoritative path into the authoritative path attribute.

[0061] In step S203, when a target file is detected to exist but lacks an authoritative path attribute in its extended attributes, an authoritative path attribute is proactively created for the file object, and the normalized path generated in step S201 is written into this extended attribute as the authoritative path. Existing files not yet included in the controlled system are immediately managed and given a unique object-level identity. By persistently storing the normalized path in the file object's extended attributes, it is ensured that even if the file is subsequently renamed, migrated to a directory, or its path alias changes, the authoritative path associated with its underlying object remains unchanged. This provides a stable and tamper-proof identity anchor for access control decisions, preventing security policies from failing due to path changes.

[0062] Step S204: If the target file does not exist, obtain the pre-bound carrier corresponding to the target file. The pre-bound carrier is a placeholder object that is pre-established before the target file is actually created and is used to carry the authoritative path.

[0063] In step S204, when it is detected that the target file does not yet exist (i.e., its corresponding inode node has not been allocated), the pre-binding carrier corresponding to the target file is obtained. The pre-binding carrier is a placeholder object or attribute record to be activated in advance for the target file that has not yet been actually created. Its function is to pre-carry and record the expected authoritative path information of the file before the file entity is generated. For example, the pre-binding carrier can be represented as an empty file placeholder object, a protected metadata area associated with a parent directory, a directory entry appended control structure, or an attribute table entry of an object to be created maintained by the file system.

[0064] Step S205: Write the normalized path as the authoritative path into the extended attribute or pending attribute record corresponding to the pre-bound carrier.

[0065] In step S205, the normalized path generated in step S201 is used as the authoritative path and written into the extended attribute or pending attribute record corresponding to the pre-bound carrier obtained in step S204. Step S205 establishes the expected identity of the target file at its inception. The authoritative path information in the pre-bound carrier is persistently stored until the target file is actually created. This ensures that the identity context of the file is prepared in advance after the file creation request is issued, thereby eliminating the time difference between file creation and identity binding and reducing the security risks caused by timing races.

[0066] Step S206: After obtaining the pre-bound carrier, detect whether the process performs a target operation on the target file, wherein the target operation is the operation that triggers the allocation or reuse of the inode of the target file.

[0067] In step S206, after successfully obtaining the pre-bound carrier and writing it to the pre-bound authoritative path, the process operations targeting the target file are continuously monitored, especially whether the process has executed a target operation that triggers the allocation or reuse of the target file's inode. Target operations include, but are not limited to, file creation (such as open with the O_CREAT flag), writing content to disk, truncation and reconstruction, and other operations that cause the underlying file system to allocate a new inode or reuse an existing inode.

[0068] Step S207: If a target operation is detected, during the allocation or reuse phase of the inode, the authoritative path in the pre-bound carrier is associated with the extended attributes of the target file.

[0069] In step S207, when a target operation is detected, i.e., during the allocation or reuse phase of the inode in the file system kernel, the authoritative path stored in the pre-binding carrier is automatically associated with the extended attributes of the newly allocated or reused target file object. Step S207 implements the automatic inheritance or injection of the authoritative path, ensuring that the file object has the correct identity that is consistent with the pre-binding at the moment of its creation.

[0070] Steps S201 to S207 above achieve accurate binding and consistent maintenance of authoritative paths throughout the entire lifecycle of file objects by using path normalization, state detection, and immediate binding and pre-binding carrier mechanisms for existing and non-existent files respectively, combined with automatic injection during the kernel layer inode allocation phase. This effectively eliminates the race window between file creation and identity binding and prevents security policy bypassing due to path changes and other reasons.

[0071] According to some optional embodiments of this application, normalizing the absolute path of a target file to obtain a normalized path can be achieved through the following steps: performing at least one of the following processes on the absolute path of the target file to obtain a normalized path: merging consecutive path separators in the absolute path of the target file into a single path separator; eliminating the current directory component and the resolvable parent directory component in the absolute path of the target file, wherein the current directory component represents the path component in the absolute path that refers to the current directory and does not change the actual direction the absolute path points to, and the parent directory component represents the path component in the absolute path that refers to the previous directory and is used to trace the absolute path back one level; unifying the directory separators in the absolute path of the target file to a preset separator format; performing normalized mapping on the absolute path of the target file based on a controlled root directory or system root path; and converting the absolute path of the target file into a globally consistent path representation based on mount view information, wherein the mount view information is information representing the file system mount relationship.

[0072] Understandably, to eliminate path inconsistencies caused by differences in path representation (such as relative paths, redundant characters, symbolic link resolution, and differences in mount views), it is necessary to normalize the access path of the target file to generate a unique normalized path. This ensures that regardless of the context, mount point, or path representation of the access request, the final normalized path accurately and uniquely represents the target file's position in the file system's logical structure, thus providing a standardized benchmark for subsequent authoritative path binding and access control decisions.

[0073] In practice, normalization involves performing one or more of the following processing operations on the absolute path of the target file. First, consecutive path separators in the path are merged into a single path separator to eliminate string differences caused by input redundancy or non-standard formatting. Second, current directory components (such as path identifiers representing the current directory without changing the actual path they point to) and resolvable parent directory components (such as path identifiers representing the parent directory used to trace the path upwards) are eliminated from the path, thereby removing unnecessary navigation levels and making the path structure more compact and standardized.

[0074] Furthermore, directory separators in the absolute paths of target files can be standardized to a preset separator format to ensure consistency in path formats across different operating systems or file systems. Simultaneously, a standardized mapping of the absolute paths of target files is performed based on the controlled root directory or system root path, mapping relative or local paths to a globally unified absolute path representation. In scenarios involving complex file system environments (such as containers or multiple mount namespaces), the absolute paths of target files are further converted into a globally consistent path representation based on mount view information (i.e., information representing file system mount relationships).

[0075] The normalization process described above is illustrated below with specific examples. Assume an access request for a target file is received, with the original absolute path being / var / log / .. / log / app / . / error.log. The current directory component "." and the parent directory component ".. / " are identified and eliminated, resolving the path to / var / log / app / error.log. If the original path contains consecutive separators such as / var / / log / app / , they are merged into a single separator / var / log / app / . If the configured canonical separator format is lowercase or a specific style, the separator format is further standardized. If the path is within a container that mounts / var / log to / mnt / data / log, based on the mount view information, it can be mapped to the globally consistent path / mnt / data / log / app / error.log within the container or maintain the logical path / var / log / app / error.log on the host machine (depending on the root directory defined by the policy).

[0076] The above process eliminates inconsistencies caused by differences in path format, symbolic links, or file system views by merging redundant delimiters, parsing and eliminating components of the current and parent directories, unifying delimiter formats, mapping based on root path specifications, and combining mount view information conversion, thereby generating a unique, standard, and normalized path.

[0077] In some optional embodiments of this application, the access control method further includes the following steps: During the allocation or reuse phase of an index node, if the same index node corresponds to multiple path entries, the path entry that serves as the authoritative path is determined in the following order: If the authoritative path attribute in the extended attributes of the target file corresponding to the index node has already registered an authoritative path, the registered authoritative path is used as the authoritative path; if the authoritative path attribute in the extended attributes of the target file has not registered an authoritative path, the normalized path that was successfully written to the authoritative path attribute when the target file was first managed is used as the authoritative path; if two or more path entries simultaneously request to serve as authoritative paths, the path entry with higher priority in the access control rules is used as the authoritative path; if the authoritative path cannot be uniquely determined, the target file is determined to be in a path identity conflict state, the operation requested by the access request for the target file is rejected, and the path identity conflict state is audited and recorded, wherein the path identity conflict state is a state in which the path entry that cannot be uniquely determined as the authoritative path among the multiple path entries corresponding to the same index node.

[0078] It should be noted that when the execution of a target operation is detected and the inode allocation or reuse phase begins, if multiple possible path entries are found corresponding to the same inode, strict authoritative path determination logic must be executed to ensure the uniqueness and security of the file object's identity. The determination process follows a decreasing priority order: first, it checks whether the target file's extended attributes already have an authoritative path attribute registered. If registered, this registered authoritative path is directly used as the final authoritative path, regardless of the specific path entry that triggered the creation or reuse. This ensures that once a file object's identity is established, its authoritative path becomes a fixed core identifier, preventing changes to the file's underlying security attributes due to subsequent access or creation requests from different path entries.

[0079] If the authoritative path is not registered in the extended attributes of the target file, it indicates that the file object has not yet been fully incorporated into the controlled system or is in the initial binding stage. In this case, the normalized path that was successfully written to the authoritative path attribute when the target file was first incorporated into the system is taken as the authoritative path. This means that among multiple competing paths, only the first entry point to successfully complete the binding operation will obtain the authoritative path status. This determination principle can ensure the certainty and consistency of authoritative path determination in the absence of predefined priorities, avoiding identity ambiguity caused by concurrent creation.

[0080] Furthermore, if two or more path entries simultaneously request to be the authoritative path, and the policy defines a clear priority order, the normalized path corresponding to the path entry with the higher priority in the access control rules will be designated as the authoritative path. For example, paths under specific critical directories (such as / etc / security / ) can be configured to have higher priority than ordinary user directories. Through this policy-priority-based mechanism, path conflicts can be automatically resolved in complex concurrent scenarios according to preset security policies, ensuring that high-security business paths obtain authoritative status.

[0081] If, after all the above judgment steps, a unique authoritative path still cannot be determined, the target file will be considered to be in a path identity conflict state. In this state, all access requests for the target file will be denied, and detailed audit logs will be recorded. A path identity conflict state refers to an abnormal state where multiple path entries corresponding to the same inode cannot establish a unique authoritative path due to a lack of registered attributes, a clear initial management record, and a lack of policy priority, resulting in this inability to establish a unique authoritative path. By denying access and performing audits, the risk of security policy bypassing due to unclear or conflicting identities can be effectively prevented, ensuring the rigor of mandatory access control.

[0082] The above logic is explained below with reference to specific embodiments. Assume a file object is represented by inode_12345, and initially, its extended attributes do not include an authoritative path attribute. User A creates this file via the path / home / userA / data.txt, manages it, and writes it to the normalized path / home / userA / data.txt as the authoritative path. Then, the configuration policy is obtained, which specifies that / secure / data.txt has a higher priority than / home / userA / data.txt. If user B then attempts to make / secure / data.txt point to the same inode_12345 through a hard link or renaming operation, it detects that / home / userA / data.txt is already registered in the extended attributes, therefore / home / userA / data.txt is still considered the authoritative path, and access via / secure / data.txt is denied (unless the policy allows aliases).

[0083] In another scenario, where a file is not yet managed, and two processes, P1 and P2, simultaneously attempt to create new files pointing to the same inode via the paths / var / log / app.log and / tmp / app.log respectively, with no priority defined in the policy: If P1 successfully writes first, / var / log / app.log becomes the authoritative path, and P2's path only serves as a non-authoritative entry point; if the competition between the two processes prevents the system from determining who wrote first or if a logical conflict exists, it is determined to be a path identity conflict, and the operations of P1 and P2 are rejected, an audit event is recorded, and the administrator is prompted to intervene.

[0084] The above process establishes a hierarchical judgment logic based on registered attributes as the priority, first-time management as the second priority, and policy priority as the third priority. When access cannot be uniquely determined, access is denied and auditing is conducted. This achieves accurate and unique determination of the authoritative path under multiple path entry points of the same index node, effectively eliminating path identity ambiguity and conflict, and thus preventing the risk of security policy bypass due to multiple path aliases.

[0085] As some optional embodiments of this application, the access control method further includes the following steps: upon receiving a deletion request for a target file, detecting whether an authoritative path attribute exists in the extended attributes of the target file; if the authoritative path attribute does not exist in the extended attributes of the target file, deleting the target file according to a preset deletion process; if the authoritative path attribute exists in the extended attributes of the target file, retaining the pre-bound carrier corresponding to the authoritative path of the target file and retaining the authoritative path attribute, wherein retaining the pre-bound carrier includes any of the following methods: blocking the physical deletion of the target file; converting the target file into an empty content object before the deletion transaction corresponding to the deletion request is committed; after the target file is deleted, re-establishing the pre-bound carrier in the original path of the target file and restoring the authoritative path attribute.

[0086] It's worth explaining that upon receiving a deletion request for a target file, the system first checks whether the target file's extended attributes contain an authoritative path attribute that identifies its security identity. This check distinguishes between controlled and uncontrolled files, ensuring the continuity of security policies at the end of the file's lifecycle. If the check shows that the target file's extended attributes do not contain an authoritative path attribute, it indicates that the file is not included in the system's mandatory access control system, or that its security identity has been unbound through other mechanisms. In this case, the system directly performs a physical deletion operation according to the preset normal deletion process, releasing the storage resources occupied by the file without affecting the normal operating efficiency of the system.

[0087] If the detection results show that the target file has an authoritative path attribute in its extended attributes, it indicates that the file is under control, and its identity is tightly bound to a specific authoritative path. To prevent attackers from bypassing access control by using a "delete first, rebuild later" approach (i.e., deleting a controlled file and immediately creating a new file in the same path to inherit or reset its identity, thereby circumventing the original policy restrictions), a retention measure is taken. Specifically, the pre-bound carrier corresponding to the authoritative path of the target file is retained, and the original authoritative path attribute is preserved. This means that although the file content may be cleared or the file handle may be closed, the file object is logically still considered a controlled object, its path identity is locked, and any new creation or access attempt to that path will be subject to the original authoritative path policy.

[0088] The methods for preserving the pre-bound carrier and maintaining the authoritative path attribute include, but are not limited to, one of the following three strategies. The first method is to block the physical deletion of the target file, i.e., intercept the deletion request at the file system level, ensuring that the file still visually or logically exists in its original path, thus ensuring continued control. The second method is to convert the target file into an empty content object before the deletion transaction corresponding to the deletion request is committed, i.e., clear the file data but retain its metadata (including extended attributes), so that the file object still occupies the original path and holds the authoritative path attribute. The third method is to automatically re-establish the pre-bound carrier (such as an empty file placeholder object) in the original path of the target file after the target file is deleted, and restore the original authoritative path attribute. By using any of these three methods, it can be ensured that even if the file entity is removed, its path identity remains anchored, preventing identity hijacking or policy bypass.

[0089] The following describes the above retention mechanism with specific examples. Assume a configuration policy prohibits the process `malicious_app` from accessing ` / etc / secure / config.key`, and this file is bound to the authoritative path ` / etc / secure / config.key`. When `malicious_app` attempts to delete the file via a system call, it detects the presence of the authoritative path attribute in its extended attributes. If the first blocking method is used, an error is returned directly; the file still exists, and `malicious_app` cannot delete it. If the second method of emptying the content is used, the file's content is cleared, but its inode and extended attributes are retained; the file still exists but its content is empty, and `malicious_app` cannot obtain the original key content. If the third method of rebuilding the pre-bound carrier is used, the deletion operation is allowed to complete, but after the deletion transaction is committed, the kernel automatically creates an empty file in the original path ` / etc / secure / config.key` as a pre-bound carrier and writes the authoritative path attribute to it. At this point, if `malicious_app` attempts to recreate the file with the same name, it will detect that the pre-bound carrier already exists in that path and decide whether to allow or deny creation based on the policy, thereby preventing attackers from bypassing the original access control restrictions by quickly rebuilding the file.

[0090] The above process effectively prevents attackers from bypassing access control by taking measures such as blocking physical deletion, converting to an empty object before transaction commit, or rebuilding the pre-bound carrier in situ after deletion when the existence of the authoritative path attribute is detected, thus ensuring the continued validity of the identity of the controlled file path and the continuity of the security policy.

[0091] Figure 3 This is a flowchart illustrating a method for determining whether to allow an access request for an operation, according to an embodiment of this application. Figure 3 As shown, the method includes the following steps:

[0092] Step S301: Detect whether there is a path identity conflict in the target file. A path identity conflict is when there are two or more conflicting authoritative paths corresponding to the same inode, or when an authoritative path is missing and is defined as abnormal by the access control rules.

[0093] Step S302: If there is no path identity conflict in the target file, check whether the authoritative path in the extended attributes of the target file is consistent with the controlled path declared by the access control rules.

[0094] Step S303: If the authoritative path and the controlled path are the same, detect whether the access path belongs to the authorized access entry corresponding to the authoritative path. The authorized access entry includes at least one of the authoritative path itself and the controlled alias entry allowed by the access control rules.

[0095] Step S304: If the access path belongs to an authorized access entry point, determine whether the subject attribute and access type meet the operation permissions for the authoritative path according to the access control rules.

[0096] Step S305: If both the subject attribute and access type satisfy the operation permissions for the authoritative path, allow the operation requested by the access request.

[0097] Specifically, step S301 is executed first to detect whether the target file has path identity conflicts. Path identity conflicts are defined in two scenarios: first, the same inode corresponds to two or more conflicting authoritative paths, meaning the file object has multiple mutually exclusive identities at the metadata level; second, an authoritative path is missing, and access control rules define this missing state as an anomaly (e.g., default denial or requiring manual intervention). If either of these conflict scenarios is detected, access can be directly denied or the process can be initiated to ensure the uniqueness and clarity of the controlled object's identity.

[0098] After confirming that there are no path identity conflicts with the target file, proceed to step S302 to check whether the authoritative path recorded in the target file's extended attributes is consistent with the controlled path declared in the access control rules, in order to verify whether the current identity of the file object conforms to the controlled scope expected by the policy. If the authoritative path is inconsistent with the controlled path declared in the rules, it indicates that the file may have been moved to an unauthorized area, or its identity may have been tampered with, and access will be denied or the corresponding governance mechanism will be triggered. Only when the two are consistent is it indicated that the file object is logically still within the controlled boundary protected by the policy, thus allowing the process to continue to execute.

[0099] Further, step S303 is executed to detect whether the access path initiating the access request belongs to the authorized access entry point corresponding to the authoritative path. Authorized access entry points include not only the authoritative path itself, but also controlled alias entry points explicitly allowed in access control rules (such as hard link paths, bound mount paths, etc.). The purpose of this step is to prevent access to controlled files through unauthorized path entry points (such as maliciously created soft links, unregistered hard links, etc.). If the access path does not belong to any authorized entry point set, even if the file identity is correct, the access attempt will be rejected, thereby blocking bypass attacks via path aliases.

[0100] After confirming that the access path is a legitimate entry point, step S304 is executed. Based on the access control rules, it is further determined whether the attributes of the requesting subject (such as process user ID, group ID, security context, etc.) and the operation type (such as read, write, execute, delete, etc.) both meet the operation permissions defined for that authoritative path. Step S304 ensures that only subjects with the corresponding permissions can perform specific operations on the controlled file. If both the subject attributes and the access type meet the permission requirements, step S305 is executed, allowing the requested operation; otherwise, access is denied and an audit log is recorded.

[0101] The following example illustrates the above process. Assume the policy stipulates that the process app_client (the principal) is only allowed to read files located at the authoritative path / etc / app / config.yaml via the authorized entry point / etc / app / config.yaml or the controlled alias / var / lib / app / config_link.

[0102] Identity conflict detection (S301): User root creates a symbolic link using the command `ln -s / etc / app / config.yaml / tmp / sneaky_link` and attempts to access it via ` / tmp / sneaky_link`. The system detects that the authoritative path in the file's extended attributes is ` / etc / app / config.yaml`, and there are no other conflicting authoritative paths. Therefore, there is no path identity conflict, and the process proceeds to the next step.

[0103] Path consistency check (S302): Read the authoritative path / etc / app / config.yaml and compare it with the controlled path / etc / app / config.yaml declared in the policy. If they match, proceed to the next step.

[0104] Entry point legitimacy check (S303): Checks whether the currently accessed path / tmp / sneaky_link belongs to an authorized entry point. The policy only allows / etc / app / config.yaml and / var / lib / app / config_link. / tmp / sneaky_link is not among them, therefore it is determined to be an illegal entry point, access is directly denied, and the process terminates.

[0105] Permission verification (if the entry point is legitimate): Assuming the user accesses ` / etc / app / config.yaml` through the legitimate path, the process proceeds to S304. It checks if the principal `app_client` has read permissions and if the operation type is read. If the policy allows, the process proceeds to S305, allowing access. If the user attempts to write, the request is denied due to a mismatch in operation type.

[0106] Steps S301 to S305 above achieve closed-loop control from object identity uniqueness to access entry legitimacy to operation permission compliance through multi-level filtering based on path identity conflict detection, authoritative path and controlled path consistency verification, authorized entry identification and subject operation permission determination. This effectively prevents security bypass risks caused by identity conflict, path alias abuse and permission overreach.

[0107] As some optional embodiments of this application, the access control method further includes the following steps: when there is no authoritative path in the extended attributes of the target file, the access request is processed according to a preset processing mode, wherein the preset processing mode is any one of default denial, default audit only, and compatibility allow; the judgment result of whether to allow the operation requested by the access request is recorded, wherein when the access path is inconsistent with the authoritative path, the access path, the authoritative path, and the audit event of the inconsistency between the access path and the authoritative path are recorded; when the authoritative path is inconsistent with the controlled path, the operation requested by the access request is denied; when the access path does not belong to the authorized access entry point, the operation requested by the access request is denied; when the subject attribute and / or access type do not meet the operation permissions for the authoritative path, the operation requested by the access request is denied.

[0108] Understandably, when the extended attributes of a target file do not contain an authoritative path, it indicates that the file has not yet completed identity binding or is in an unmanaged state. In this case, access requests are handled according to preset processing modes. Preset processing modes include three scenarios: default denial, default audit only, and compatibility allowance. In default denial mode, any access request for the file is directly denied to ensure that files without bound identities are not accessed accidentally, suitable for high-security scenarios. In default audit only mode, access requests are allowed, but detailed audit logs are recorded for subsequent analysis, suitable for transitional periods or low-risk scenarios. In compatibility allowance mode, access is allowed while implementing stricter monitoring or restrictions (such as read-only access) and audit events are recorded, suitable for scenarios requiring a gradual migration strategy. This flexible preset mechanism allows administrators to balance security and availability based on specific security needs and business scenarios.

[0109] For target files bound to authoritative paths, strict multi-dimensional consistency checks and permission determinations are performed, and all determination results are recorded. First, the consistency between the access path and the authoritative path is checked. If they are inconsistent, such as accessing the file via hard links, bound mounts, or unauthorized alias paths, it is considered a potential security risk. An event containing the access path, authoritative path, and inconsistent state is recorded, and access is denied according to a preset policy (such as strict denial). Second, the consistency between the authoritative path and the controlled path declared in the access control rules is checked. If the authoritative path deviates from the expected controlled scope of the policy, it indicates that the file may have been illegally migrated or tampered with; access is directly denied to prevent the controlled boundary from being breached.

[0110] Furthermore, even if the paths are identical, it is necessary to verify whether the access path is an authorized access entry point. Authorized access entry points include the authoritative path itself and controlled alias entry points explicitly permitted by the policy. If the current access path is not listed in the authorized entry point list, access is denied, thereby blocking access attempts made through unregistered paths.

[0111] Finally, the attributes of the entity initiating the access (such as user identity, process context, etc.) and the type of operation (such as read, write, execute, etc.) are checked to ensure they meet the required permissions for the authoritative path. If the entity does not have the corresponding permissions or the operation type is prohibited, access is denied. All of the above denial or permission decisions are recorded in the audit log, forming a complete chain of evidence for access control, facilitating security audits, troubleshooting, and compliance checks.

[0112] The following example illustrates the above processing logic. Assume the policy stipulates that the authoritative path to the file / etc / secure / db.conf is / etc / secure / db.conf, and that user db_admin is only allowed to perform read operations via the path / etc / secure / db.conf or the controlled alias / var / lib / db / db.conf, while writing is prohibited.

[0113] No authoritative path scenario: If the file / tmp / unmanaged.txt has no authoritative path attribute and the default mode is "default audit only", user1 attempts to read the file. Reading is allowed, but an audit log is recorded, and the file is marked as having no authoritative path.

[0114] Inconsistent path scenario: User user1 accesses / etc / secure / db.conf via a hard link / tmp / link_to_db. The system detects that the authoritative path is / etc / secure / db.conf, while the access path is / tmp / link_to_db, which is inconsistent. An audit event is logged (access path: / tmp / link_to_db, authoritative path: / etc / secure / db.conf), and access is denied based on strict denial mode.

[0115] Controlled path inconsistency scenario: An administrator mistakenly moves a file to ` / tmp / secure_backup / db.conf` but fails to update the policy or authoritative path binding. In this case, the authoritative path remains ` / etc / secure / db.conf`, but the controlled paths declared in the policy may not include ` / tmp / secure_backup / db.conf` (assuming the policy restricts the controlled path prefix to ` / etc / `). Upon detecting the inconsistency between the authoritative path and the controlled policy, access is denied.

[0116] Unauthorized entry scenario: User user1 attempts to access a file via a newly created symbolic link / home / user1 / db_link. Although the authoritative path is correct, / home / user1 / db_link is not in the authorized entry list. Access is denied and an audit event is logged.

[0117] Permission violation scenario: User user1 (not db_admin) attempts to write to the file / etc / secure / db.conf through the authorization entry point. The system verifies that the user's attributes do not meet write permissions, denies access, and logs an audit event.

[0118] The above process implements a flexible preset processing mode for files without authoritative paths, and strictly verifies and audits path consistency, entry legitimacy, and subject permissions. This enables differentiated management of unmanaged objects and comprehensive monitoring of the access behavior of managed objects, effectively eliminating security blind spots and improving audit traceability.

[0119] Figure 4 This is a flowchart of another method for determining whether to allow an access request for an operation, according to an embodiment of this application. Figure 4 As shown, the method includes the following steps:

[0120] Step S401: Obtain the priority mode in the access control rule, wherein the access control rule declares a controlled path, and the controlled path is the path identity declared by the access control rule and managed by the access control rule; the authoritative path corresponds to an authorized access entry, and the authorized access entry includes at least one of the authoritative path itself and the controlled alias entry allowed by the access control rule.

[0121] Step S402: If the priority mode indicates the first priority mode, and the authoritative path is consistent with the controlled path, the access path belongs to the authorized access entry, and the subject attribute and access type meet the operation permissions for the authoritative path defined by the access control rules, the operation requested by the access request is allowed; otherwise, the operation requested by the access request is denied.

[0122] Step S403: If the priority mode indicates the second priority mode, and the authoritative path is missing or the access path is inconsistent with the authoritative path, the access request is audited and logged before the operation requested by the access request is allowed.

[0123] It's worth explaining that the access control method supports configuring different priority modes to adapt to diverse security needs and business scenarios. These priority modes can include a first-priority mode and a second-priority mode. The first-priority mode embodies strict security control principles, and its core logic is that all security conditions must be met simultaneously before access is granted.

[0124] Specifically, when the priority mode is set to first priority, the system first verifies whether the authoritative path of the target file matches the controlled path declared in the access control rule, ensuring that the file object's identity is within the expected controlled scope. Then, it verifies whether the current access path belongs to the authorized access entry point corresponding to the authoritative path. The authorized access entry point includes the authoritative path itself and controlled aliases allowed by the policy, preventing bypassing control through unauthorized paths. Finally, it verifies whether the attributes of the initiating access subject (such as user identity, process context, etc.) and the operation type (such as read, write, execute, etc.) meet the permissions defined in the rule. Only when all three conditions—path identity consistency, entry point legitimacy, and subject permissions compliance—are met, is the operation requested by the access request allowed; if any one condition is not met, the access request is directly rejected.

[0125] The second priority mode prioritizes compatibility and a smooth transition, suitable for policy migration periods or scenarios where availability needs to be considered. In this mode, control logic is relatively lenient, focusing primarily on auditing rather than forced blocking. Specifically, when the priority mode is set to second priority, two key abnormal states are detected: first, the authoritative path of the target file is missing, indicating that the file has not yet completed identity binding or is in an unmanaged state; second, the current access path is inconsistent with the authoritative path in the file's extended attributes, indicating the existence of path aliases or view changes. If either of these situations is detected, a detailed audit log is first created for the access request, including the access path, authoritative path (if it exists), subject information, and operation type, before the requested operation is allowed to execute. The second priority mode mechanism ensures that business access will not be interrupted by strict security policies in cases of incomplete identity binding or complex path environments, while simultaneously preserving the data foundation for subsequent tracing and governance through audit logs.

[0126] The following describes the two priority modes with specific examples. Assume there are two access control rules in the system: rule A applies to / etc / app / config.yaml, and rule B applies to the / var / log / app / directory.

[0127] First priority mode (strict mode). Rule A is set to first priority mode. The file / etc / app / config.yaml is already bound to the authoritative path / etc / app / config.yaml.

[0128] Legitimate Access: The process app_proc (the main process) performs a read operation through the path / etc / app / config.yaml (the authorized entry point). Verification: The authoritative path matches the controlled path (yes); the access path belongs to the authorized entry point (yes); the main process app_proc has read permissions (yes). If all conditions are met, access is permitted.

[0129] Unauthorized entry: Process app_proc accesses the same file via a hard link / tmp / link_config. Verification: The authoritative path matches the controlled path (yes); the accessed path / tmp / link_config is not an authorized entry point (no, unless explicitly allowed by the policy). Conditions not met; access denied.

[0130] Insufficient permissions: The process user_proc (the subject without permissions) attempted to write to the path / etc / app / config.yaml. Verification: The authoritative path matches the controlled path (Yes); the access path belongs to an authorized entry point (Yes); the subject user_proc lacks write permissions (No). Conditions are not met; access is denied.

[0131] Second priority mode (compatibility / audit mode). Set rule B to second priority mode to handle log directories that are being migrated.

[0132] Authoritative path missing: The newly created log file / var / log / app / new.log has not yet been managed, and there is no authoritative path in its extended properties. Validation: Authoritative path missing (yes). Perform audit logging (log file path, lack of authoritative path status), then allow access.

[0133] Path inconsistency: The administrator migrated the log directory from / var / log / app / to / data / logs / app / , but some old files still haven't had their authoritative paths updated, and their authoritative paths still point to / var / log / app / old_path. When a process accesses the file via the new path / data / logs / app / old_file, a check is performed: the access path is inconsistent with the authoritative path (yes). An audit log is created (recording the access path, authoritative path, and reason for the inconsistency), and then access is allowed to ensure uninterrupted business operations during the migration.

[0134] Full compliance: If the authoritative path to the file is correct and the path is consistent, access is also allowed and audit logs are recorded to ensure that all access behavior is traceable.

[0135] By introducing two differentiated processing modes, namely first priority and second priority, multiple verifications of path identity, entry legitimacy, and subject permissions can be achieved in strict security scenarios, as well as flexible control for unmanaged or inconsistent objects to be audited and then allowed to pass in compatible transition scenarios, thus balancing security strength and business availability.

[0136] According to some preferred embodiments of this application, the access control method further includes the following steps: when the priority mode indicates a third priority mode, if the access path is inconsistent with the authoritative path, after rejecting the operation requested by the access request, at least one of controlled relocation and alias registration is performed on the access request; wherein, controlled relocation is the process of redirecting the access request to the authorized path under controlled conditions, and alias registration is the process of registering the access path as a controlled alias entry of the authoritative path; when the priority mode indicates a fourth priority mode, if the trusted subject meets the preset additional constraints, the trusted subject is allowed to perform path identity restoration; wherein, the trusted subject is the subject granted governance permissions by the access control rules, and path identity restoration is the process of correcting the authoritative path of the target file.

[0137] This embodiment further introduces a third priority mode and a fourth priority mode to provide a dynamic governance and repair mechanism for inconsistent paths or abnormal identities, thereby achieving a balance between strict security control and flexible operation and maintenance management.

[0138] When the priority mode is set to third priority mode, path inconsistency issues are resolved through automated or semi-automated governance processes, rather than simply denying access. Specifically, when an access path is detected to be inconsistent with the authoritative path in the target file's extended attributes, after denying the operation requested by the current access request, at least one of the following processes is triggered: controlled relocation or alias registration. Controlled relocation refers to automatically redirecting the current access request to the correct authorized path under specific controlled conditions (such as trusted subject, restricted operation type, etc.), allowing access to continue while maintaining the authoritative path. Alias ​​registration involves registering the current access path as a controlled alias entry point for the authoritative path, making future access via that path considered legitimate. Third priority mode allows for dynamic updates to the policy view when new legitimate access entry points are discovered, reducing the management burden caused by directory structure changes or temporary mountings, while ensuring all access remains within a controlled scope.

[0139] When the priority mode is set to fourth priority mode, the focus is on authorized administrators or trusted entities proactively correcting incorrectly bound path identities. In fourth priority mode, if a path identity anomaly is detected (such as an incorrect, missing, or conflicting authoritative path), normal access will be denied. However, if the requesting entity is identified as a trusted entity (i.e., a management process or administrator account with specific governance privileges), and that entity meets preset additional constraints (such as the need for secondary authentication, operation logging, specific time window restrictions, etc.), then the trusted entity is allowed to perform path identity correction operations. Path identity correction refers to the process of correcting, updating, or rebinding the authoritative path in the target file's extended attributes; for example, correcting an incorrect authoritative path to a correct controlled path, or establishing the correct binding for a file with a missing authoritative path. Fourth priority mode provides reset capabilities after emergency braking, ensuring that the correct access control state can be quickly restored in the event of misconfiguration or policy migration errors.

[0140] The third priority mode and the fourth priority mode are described below with reference to specific embodiments.

[0141] Third priority mode: Assuming the policy specifies / etc / app / config.yaml as the controlled path, and the authoritative path is already bound to / etc / app / config.yaml. The issue arises because the operations script incorrectly created a symbolic link to / tmp / app_link, and the application accesses it through / tmp / app_link.

[0142] Scenario A (Alias ​​Registration): An inconsistency is detected between the access path / tmp / app_link and the authoritative path / etc / app / config.yaml. In third-priority mode, write operations are denied, but logs are logged and / tmp / app_link is automatically registered as a controlled alias entry point for that authoritative path. The next time an application accesses / tmp / app_link, it will be treated as a legitimate entry point and allowed access (if permissions match).

[0143] Scenario B (Controlled Relocation): If controlled relocation is configured to be enabled, when an application accesses / tmp / app_link, access to the current path is denied. However, the kernel layer redirects file system calls to the authorized entry point / etc / app / config.yaml, allowing the application to complete the operation through the correct path without being aware of it, and without modifying any policies or attributes.

[0144] Fourth priority mode: Suppose the administrator mistakenly binds the authoritative path of the file / var / data / db.bin to the incorrect / var / data / db_old.bin, causing normal business operations to be unable to access it.

[0145] Regular user: Attempting to access / var / data / db.bin, access is denied because the authoritative path / var / data / db_old.bin is inconsistent with the controlled path / var / data / db.bin (assuming policy declaration).

[0146] Trusted Entity (Administrator Process admin_tool): The administrator runs admin_tool. This entity is granted governance privileges and meets additional constraints (such as requiring an administrator password). admin_tool initiates a request to perform path identity restoration on / var / data / db.bin. After successful verification, admin_tool is allowed to correct the authoritative path in the file's extended attributes from / var / data / db_old.bin to / var / data / db.bin. After the restoration is complete, normal business access can be restored.

[0147] By introducing a third priority mode to enable automatic controlled relocation or alias registration when paths are inconsistent, and a fourth priority mode to support the restoration of the path identity of trusted entities under certain constraints, the problem of access blocking caused by path changes or configuration errors is effectively solved. While ensuring the bottom line of security, it can improve the flexibility of operation and maintenance and business continuity.

[0148] According to some preferred embodiments of this application, the access control method further includes the following steps: when the access request is a path migration operation, the directory entry movement of the target file and the update of the authoritative path in the extended attributes of the target file are processed as the same transaction, wherein the path migration operation is an operation that changes the path of the target file; when the file system where the target file is located supports a transaction mechanism or a logging mechanism, the directory entry movement and the update of the authoritative path are executed as the same atomic commit unit; when the file system where the target file is located does not support a transaction mechanism and does not support a logging mechanism, the directory entry movement and the update of the authoritative path are executed according to a preset transaction process, so that the directory entry movement and the update of the authoritative path take effect simultaneously or do not take effect simultaneously, wherein the preset transaction process includes pre-checking the directory entry movement and the update of the authoritative path, retaining the old state, performing verification after commit, and rolling back when it fails; when the directory entry movement succeeds but the update of the authoritative path fails, the target file enters an abnormal protection state, wherein the abnormal protection state includes at least one of blocking the current operation from taking effect, rolling back the directory entry movement, marking the target file as mismatched and rejecting the operation requested by subsequent access requests for the target file, and only allowing trusted repair processes to process the target file.

[0149] It's worth explaining that when the access request is a path migration operation (such as renaming or directory moving), this embodiment employs an atomic transaction mechanism to ensure the synchronous consistency between the file directory entry movement and the authoritative path update in the extended attributes. This prevents inconsistencies such as a changed path but unchanged identity or a changed identity but unchanged path, thereby eliminating security vulnerabilities. Specifically, it first determines whether the file system containing the target file supports atomic transaction or logging mechanisms. If the file system supports such mechanisms, the directory entry movement operation and the authoritative path update operation are directly encapsulated into the same atomic commit unit. This means that both operations succeed simultaneously and are committed to the underlying file system, or they are rolled back simultaneously if either fails, thus ensuring data consistency at the hardware or file system level and avoiding intermediate states.

[0150] If the target file system does not support atomic transaction or logging mechanisms, a pre-defined transaction process implemented in software simulates atomic operations to ensure logical synchronization between directory entry movement and authoritative path updates. This pre-defined transaction process includes four key phases: pre-check, retaining the old state, post-commit verification, and rollback on failure. In the pre-check phase, the legality of the migration target path and the feasibility of authoritative path updates are verified. In the retaining the old state phase, the current directory entry state and authoritative path value are recorded as a potential rollback baseline. In the commit phase, directory entry movement and authoritative path updates are executed sequentially. In the post-commit verification phase, it is verified that both have taken effect as expected. If an authoritative path update fails during execution (e.g., insufficient permissions, incorrect extended attribute writes), a rollback mechanism is triggered, undoing the completed directory entry movement and restoring the file to its pre-migration state, thus ensuring that the file remains in a controlled and consistent state.

[0151] In the special case where a directory entry move succeeds but the authoritative path update fails, the target file is placed in an anomalous protection state to block potential security risks. This anomalous protection state comprises a set of stringent defense measures, including but not limited to: preventing the migration operation from taking effect (i.e., refusing to complete the migration), automatically rolling back the directory entry move to restore the original path, marking the target file as having a path identity mismatch and denying all subsequent access requests to that file, or allowing only authorized remediation processes with specific governance privileges to handle the file specially. These steps ensure that even in the event of partial failure, the file will not be left in a dangerous state where it lacks a correct path identifier yet allows normal access, thus forcing administrator intervention or relying on automatic repair mechanisms to restore system integrity.

[0152] The following example illustrates the process described above. Assume the authoritative path to the file / etc / app / config.yaml is already bound to / etc / app / config.yaml, and the administrator executes the move command `mv / etc / app / config.yaml / backup / config.yaml`.

[0153] Example 1: File systems that support transaction mechanisms (such as ext4withjournaling).

[0154] Atomic execution: Upon detecting that the file system supports logging, the deletion of the directory entry for / etc / app / config.yaml and the creation of / backup / config.yaml are encapsulated in a single transaction, along with updating the authoritative path in the file's extended attributes from / etc / app / config.yaml to / backup / config.yaml.

[0155] Results: If both succeed, the file is located at / backup / config.yaml, the authoritative path is updated to / backup / config.yaml, and business access is normal; if the extended attribute update fails due to permission issues, the entire transaction is rolled back, the file remains at / etc / app / , the authoritative path remains unchanged, and access is unaffected.

[0156] Example 2: File systems that do not support transaction mechanisms.

[0157] Pre-check: Check if write permissions exist in the / backup / directory, and whether the extended attributes are writable.

[0158] Preserve the old state: Record the current file's state in / etc / app / and its authoritative path / etc / app / config.yaml.

[0159] Perform the following steps: First, move the directory entry so that the file's physical location becomes / backup / config.yaml. Then, attempt to update the extended attributes.

[0160] Failure handling: Assume that the extended attribute update fails due to insufficient disk space or a driver bug.

[0161] Anomaly Protection: Anomaly protection is triggered when the authoritative path is not updated.

[0162] Rollback: Moves the file from / backup / back to / etc / app / , restoring it to its original state.

[0163] Alternatively, mark a mismatch: If rollback is not feasible (e.g., moving across file systems), mark the file as mismatched. In this case, any access requests via / backup / config.yaml or the original path / etc / app / config.yaml (if any remnants exist) will be denied, unless initiated by the fix_path_identity command from a trusted repair process, which allows for a forced update of the authoritative path or cleanup of the state.

[0164] The above process ensures strict synchronization between directory entry movement and authoritative path updates during path migration operations by constructing an atomic transaction mechanism and an exception protection state that adapt to the characteristics of different file systems. This effectively prevents the risk of path and identity mismatch due to update failure, thereby ensuring the consistency and security of access control policies.

[0165] According to some alternative embodiments of this application, the access control method further includes the following steps: when a target file is copied, imported, or restored, the target file is processed according to the access control rules as follows: when the access control rule indicates an inheritance policy, the authoritative path of the source object of the target file is used as the authoritative path of the target file; when the access control rule indicates a rebinding policy, a new authoritative path is bound to the target file; when the access control rule indicates a remanagement policy, the target file is identified as an object to be remanaged, and an authoritative path is determined for the target file after it is remanaged; when the access control rule indicates a trusted binding policy and the subject of the access request is a trusted subject, the trusted subject is allowed to bind an authoritative path to the target file, wherein the trusted subject is the subject granted governance authority by the access control rule.

[0166] It should be noted that when a target file undergoes copying, importing, or restoring operations, the authoritative path of the newly generated or migrated target file is initialized or redefined according to the preset identity inheritance policy in the access control rules to ensure the file's identity compliance after lifecycle changes. Specifically, the access control rules applicable to the file are first parsed, and the corresponding processing logic is executed according to the different policy types indicated by the rules. If the rule indicates an inheritance policy, the existing authoritative path of the source object (i.e., the source file) of the target file is directly assigned to the target file, thereby achieving seamless transfer of identity attributes. This is suitable for batch migration or backup and recovery scenarios to maintain the consistency of the original security context. If the rule indicates a rebinding policy, the original identity of the source file is ignored, and a new authoritative path that conforms to the current policy expectation is bound to the target file. This can be used when a file is moved to a new controlled directory structure, requiring the establishment of a new controlled identity.

[0167] For more complex scenarios, if the access control rule indicates a remanagement policy, the target file's valid authoritative path is marked as an object to be remanaged. At this point, the target file is in a restricted or isolated state until it undergoes a complete remanagement process (such as policy confirmation, administrator approval, or automated compliance checks) before being assigned a formal authoritative path. This process is suitable for importing files from untrusted areas or when system policies change, ensuring that only rigorously reviewed files can enter the controlled system.

[0168] Furthermore, if the rule indicates a trusted binding policy, a dynamic binding mechanism based on subject permissions is introduced. Only when the subject initiating the binding operation is identified as a trusted subject (i.e., a management process or administrator account with specific governance permissions) is the subject allowed to bind an authoritative path to the target file. This process provides flexibility for emergency repairs, batch imports, or special business scenarios, allowing trusted administrators to determine file identity under specific conditions while preventing ordinary users or malicious processes from arbitrarily tampering with file security attributes.

[0169] The following examples illustrate the four strategies mentioned above.

[0170] Example 1: Inheritance Policy. An administrator executes a backup command, copying ` / etc / app / secure.conf` (whose authoritative path is already bound to ` / etc / app / secure.conf`) to ` / backup / secure.conf.bak`. Access control rules for the ` / backup / ` directory are configured with an inheritance policy. Upon detecting the copy operation, the authoritative path of the source file ` / etc / app / secure.conf` is directly copied to the extended attributes of the new file ` / backup / secure.conf.bak`. The new file inherits the original identity; although the path is different, its security context remains consistent, facilitating subsequent auditing and tracing of the source.

[0171] Example 2: Rebinding Policy. An enterprise migrates an old system to a new environment, and the file ` / old_data / report.pdf` (originally with the authoritative path ` / old / report`) is imported into the ` / new_data / reports / ` directory of the new system. Access control rules are configured with a rebinding policy for the ` / new_data / ` directory. Upon detecting the import operation, the old authoritative path of the source file is ignored. Instead, based on the structure and policy of the new directory, a new authoritative path ` / new_data / reports / report.pdf` is bound to the target file ` / new_data / reports / report.pdf`, ensuring that the file has a clear, controlled identity in the new environment that conforms to the current directory structure.

[0172] Example 3: Remanagement Policy. A user imports a file ` / mnt / usb / virus_scan.exe` from an external USB drive to the company's intranet server ` / data / incoming / `. Access control rules are configured for the ` / data / incoming / ` directory as a remanagement policy. Upon detecting the file's entry, it is marked as an object to be remanaged. At this point, the file cannot be accessed by regular applications (or only read-only auditing is allowed). Only after the security scan process confirms the file is virus-free, and the administrator approves the remanagement in the management console, is the file officially assigned an authoritative path (e.g., ` / data / verified / virus_scan.exe`), making it a controlled object and allowing normal access.

[0173] Example 4: Trusted Binding Policy. An application's configuration file, ` / etc / app / config.yaml`, lost its authoritative path due to accidental deletion, causing service interruption. Ordinary users attempting to manually add the authoritative path were rejected by the system. In this situation, the system administrator used the management tool `admin_tool` (the trusted principal) with governance privileges to perform the binding via the command `admin_toolbind_path / etc / app / config.yaml`. Because `admin_tool` is a trusted principal and meets preset additional constraints (such as operation logging), it was allowed to force the binding of the authoritative path to the target file, thus quickly restoring service access and recording the repair operation for auditing purposes.

[0174] The above process flexibly adapts to identity transfer needs in file copying, importing, or restoring scenarios by setting four differentiated strategies: inheritance, rebinding, remanagement, and trusted binding. While ensuring the consistency of security policies, it can also take into account the flexibility of business continuity, compliance review, and emergency governance.

[0175] In some optional embodiments of this application, the access control method further includes the following steps: when adding a new path entry to the target file, keeping the authoritative path in the extended attributes of the target file unchanged, wherein adding the path entry includes creating a hard link to the target file and presenting the target file through different mount points or different file system views; when initiating an access request to the target file through the newly added path entry, obtaining the access path corresponding to the access request, reading the authoritative path from the extended attributes of the target file, and determining whether to allow the operation requested by the access request based on the consistency relationship between the access path and the authoritative path.

[0176] Understandably, when a new path entry is added to a target file, this embodiment ensures the uniqueness and stability of the file's identity by keeping the authoritative path in the file object's extended attributes unchanged, regardless of whether the new entry is added through creating a hard link, binding mount, or through different file system views (such as container namespaces, chroot environments, etc.). Specifically, changes in hard links, mount points, or view switching only increase the file's accessible path in the file system hierarchy and do not change the security attributes associated with the underlying inode. Therefore, when these operations are detected, the original authoritative path will not be updated or overwritten, thereby preventing the dilution or conflict of security identity caused by an increase in path entries.

[0177] When an access request is initiated to a target file through a newly added path entry, a strict consistency verification process is executed. First, the specific access path corresponding to the current access request is obtained; second, the authoritative path bound to the target file is read from its extended attributes; finally, a judgment is made based on the consistency relationship between the access path and the authoritative path. The judgment logic mainly relies on the set of authorized entry points defined in the access control rules. If the current access path equals the authoritative path, or if the current access path belongs to a controlled alias entry point allowed by the policy (e.g., an alias pre-registered for a hard link or a specific mount point), it is determined to be consistent, and access is allowed; conversely, if the current access path is neither an authoritative path nor an allowed alias, it is determined to be inconsistent, and the access request is denied. This process ensures that even if an attacker or malicious process attempts to access the file through an unexpected path entry point (such as an unauthorized hard link or temporary mount point), access will be blocked as long as the path is not included in the authorized scope, thus effectively defending against attacks based on path aliases or view obfuscation.

[0178] The above mechanism will be explained below with specific examples.

[0179] Example 1: Hard link scenario. Suppose that the authoritative path of the file / etc / app / db_config is bound to / etc / app / db_config, and the policy only allows the application process app_proc to access it through this path or the specific backup path / backup / db_config_link.

[0180] Creating a hard link: The administrator creates a hard link ` / backup / db_config_link` pointing to ` / etc / app / db_config`. The creation of the hard link is detected, but the authoritative path in the ` / etc / app / db_config` extended attributes remains unchanged, still being ` / etc / app / db_config`.

[0181] Legitimate access: app_proc accesses the file via / backup / db_config_link. It reads the authoritative path / etc / app / db_config and checks the access path / backup / db_config_link. Since this path is pre-registered as an allowed alias by the policy, it is deemed consistent and access is allowed.

[0182] Unauthorized access: User user1 created a hard link / tmp / db_config_link and attempted to access it through that path. The authoritative path / etc / app / db_config is read, and the access path / tmp / db_config_link is checked. Since this path is neither an authoritative path nor an allowed alias, it is determined to be inconsistent, and access is denied.

[0183] Example 2: Binding and Mounting Scenario. Assume the authoritative path of the file / var / data / secret.key is / var / data / secret.key.

[0184] Bind mount: The system administrator executes `bindmount / var / data / secret.key / mnt / backup / secret.key`. The authoritative path in the original file's extended attributes remains unchanged, still ` / var / data / secret.key`.

[0185] View access: The container_a mounts the / mnt / backup / directory and accesses the file within the container via / mnt / backup / secret.key. It obtains the access path / mnt / backup / secret.key and reads the authoritative path / var / data / secret.key from the file's extended attributes.

[0186] Consistency check: If the policy allows access via mount point aliases, then allow it; if the policy strictly restricts access to only authorized paths, then deny it. If no alias is configured, even if the file is physically the same, access will be denied due to path inconsistency, preventing applications within the container from bypassing the access restrictions of / var / data / .

[0187] The above process decouples file identity from path entry by keeping the authoritative path under the newly added path entry unchanged and verifying the consistency between the authoritative path and the access path during access. This effectively prevents the risk of path alias bypass caused by hard links, mount point switching or view confusion, thereby ensuring the object-level consistency and security of access control decisions.

[0188] As some optional embodiments of this application, the access control method further includes the following steps: performing at least one of the following protection processes on the authoritative path attribute of the stored authoritative path: setting the authoritative path attribute as an extended attribute under a protected namespace, wherein the authoritative path attribute is identified by a preset key value; determining the modification permission of the authoritative path attribute to only processes with preset management permissions, thereby prohibiting user-mode processes from directly modifying the authoritative path attribute; auditing the setting, modification, and deletion operations of the authoritative path attribute; and attaching at least one of the following to the attribute value of the authoritative path attribute: verification information, version information, policy identifier, and integrity protection field.

[0189] It should be noted that, to protect the authoritative path stored in file extended attributes from malicious tampering or illegal modification, this embodiment proposes a multi-layered security protection mechanism to ensure that the identity anchor function of the authoritative path is not compromised. First, the authoritative path attribute is defined under a specific protected namespace and identified using a preset key-value pair (such as security.authoritative_path). The namespace isolation mechanism utilizes the naming conventions of Linux file system extended attributes to distinguish the authoritative path from user-defined extended attributes, preventing ordinary users from overwriting or forging it using common attribute namespaces (such as user. or trusted.).

[0190] Secondly, at the access control level, permissions to modify authoritative path attributes are strictly limited. Only kernel modules or processes with specific preset management privileges (such as system security agents or trusted governance tools) are allowed to modify, set, or delete this attribute. Even if ordinary user-space processes have file ownership or write permissions, they cannot directly modify authoritative path attributes.

[0191] Furthermore, to ensure traceability and integrity, all critical operations on authoritative path attributes (including setting, modifying, and deleting) are subject to separate audit logging. Any attempt to change the authoritative path is recorded in the security audit log, including the operator, operation type, timestamp, and result, for subsequent security audits and troubleshooting.

[0192] Furthermore, in scenarios with higher security levels, additional verification information (such as hash checksums), version control information, policy identifiers, or integrity protection fields can be added to the attribute values ​​of authoritative paths. These additional fields can detect whether attribute values ​​have been tampered with or confirm whether the attribute belongs to the currently effective policy version, thereby enhancing the ability to combat advanced persistence threats and insider attacks.

[0193] The above protection mechanism will be explained below with specific examples.

[0194] Example 1: Namespace isolation and permission restrictions.

[0195] Suppose a malicious user attacker creates a file named / public / data.txt and attempts to disguise it as a controlled file by modifying its extended attributes to bypass access restrictions.

[0196] The attacker attempted to execute the command `setfattr -nuser.authoritative_path -v " / etc / secret" / public / data.txt`. Because the authoritative path must be located within the `security.` namespace, and ordinary users do not have permission to write to the `security.` namespace, the operation was rejected by the kernel, returning a permission error.

[0197] The attacker attempted to use `setfattr -nsecurity.authoritative_path -v " / tmp / hack" / public / data.txt`. However, because the attacker lacked the pre-defined administrative privileges (such as CAP_MAC_ADMIN or specific SELinux / LSM privileges), the request was intercepted and refused execution, triggering an audit log alert.

[0198] Example 2: Suppose a system administrator needs to fix a misbound file / etc / app / broken.conf, whose authoritative path incorrectly points to / etc / app / old.conf.

[0199] Trusted operation: The system administrator uses the trusted governance tool fix_tool (with default management privileges) to execute fix_toolbind / etc / app / broken.conf / etc / app / broken.conf.

[0200] Integrity verification and auditing: When fix_tool writes the new authoritative path to the file extension attributes, it not only writes the path string, but also appends the current policy version number v2.1 and a hash check value generated based on the path and administrator ID.

[0201] Audit Log: The write request was intercepted. After verifying the permissions of fix_tool, the write operation was performed, and this "modification" operation was recorded in the audit log. The log entry contains: Action:UPDATE_ATTR,Subject:fix_tool,Object: / etc / app / broken.conf,New_Value: / etc / app / broken.conf,Version:v2.1,Hash:hash(...),Timestamp:2026-03-25T10:00:00Z.

[0202] Subsequent verification: When subsequent access requests arrive, in addition to comparing path consistency, the attached hash value and version number are also read and verified to ensure that the authoritative path has not been tampered with by subsequent unauthorized processes. If the hash value does not match, even if the path string is correct, it is considered an anomaly and access is denied.

[0203] The above process uses multiple mechanisms, including namespace isolation, access control, operation auditing, and integrity protection, to comprehensively prevent the authoritative path attribute from being illegally tampered with or forged, ensuring the non-repudiation and security of file identity.

[0204] This application also provides an access control method. Taking the application process appd accessing the configuration file / etc / app / config.yaml as an example, the processing flow of this application under normal access, path alias attack, and "delete then create" attack scenarios is illustrated. The specific steps are as follows:

[0205] 1. Strategy configuration and binding with authoritative paths.

[0206] The administrator configures an access control policy that allows only the application process appd to read the file / etc / app / config.yaml. The system then performs authoritative path binding based on this policy.

[0207] If the file already exists: write the normalized path / etc / app / config.yaml into the extended attributes (such as security.authoritative_path) of that file object to establish its authoritative status.

[0208] If the file does not yet exist: initiate the pre-binding mechanism, create a pre-binding carrier (preferably an empty file placeholder object) under this path, and write the authoritative path / etc / app / config.yaml into the carrier or the attribute record to be effective, thereby establishing the controlled identity before the actual content of the file is generated.

[0209] 2. Normal access verification.

[0210] When the application process appd initiates a read request to / etc / app / config.yaml, the following decision process is executed:

[0211] Information Acquisition: Capture access requests, parse the current access path to / etc / app / config.yaml, identify the subject as appd, and locate the inode of the target file.

[0212] Authoritative path reading: Reads the bound authoritative path / etc / app / config.yaml from the extended attributes of the target file.

[0213] Consistency verification and authorization decision: Determine if the current access path ` / etc / app / config.yaml` matches the authoritative path and belongs to an authorized entry point permitted by the policy; simultaneously verify that the principal `appd` has read permissions. If the above conditions are met, the access is deemed legitimate, and the read operation is allowed.

[0214] 3. Protection against path alias attacks (hard link scenarios).

[0215] If an attacker creates a hard link / tmp / cfg for that file and attempts to access the same inode file through that new path, the following protection logic will be executed:

[0216] Identity verification: The access path / tmp / cfg was obtained, and the authoritative path in the extended attributes of this inode was read. It was found that it is still / etc / app / config.yaml, which has not changed due to the creation of hard links.

[0217] Entry point verification: Determine if the current access path / tmp / cfg is not an authoritative path and is not included in the set of controlled alias entries allowed by the policy.

[0218] Access Denied: Based on the principle of prioritizing authoritative paths, access is determined to be inconsistent, read requests are denied, and an audit log containing the current path, authoritative path, and reason for denial is recorded, thereby effectively blocking path alias bypass attacks using hard links.

[0219] 4. Protection against "delete first, then create" attacks (pre-binding mechanism scenario).

[0220] If an attacker attempts to bypass control by deleting the original file and recreating it at the same path, a pre-binding mechanism can be used for defense:

[0221] State maintenance: When the original file is deleted, the pre-bound carrier associated with the path and its authoritative path binding relationship are still detected (e.g., by retaining placeholder objects or metadata records).

[0222] Continuous control: When an attacker attempts to recreate the file / etc / app / config.yaml in the same path, the attacker recognizes that the path is already under control and inherits or activates the original authoritative path binding relationship.

[0223] Policy enforcement: Newly created files automatically inherit the authoritative path, and access requests continue to be validated according to existing policies. If the access subject or path does not meet the policy requirements, it will still be denied, thereby preventing attackers from resetting or bypassing security controls by rebuilding files.

[0224] Through the above process, this embodiment achieves a fundamental shift in access control decision logic: the core of access permission determination changes from the instantaneously resolved file path to the authoritative path persistently bound to the file object's extended attributes. The current access path serves only as auxiliary information for authorization entry identification and consistency verification. This process ensures that even in complex scenarios such as path aliases (hard links), view switching, or "delete before create," as long as the authoritative identity of the file object remains unchanged or unauthorized, the access control policy remains strictly consistent, effectively eliminating the security risks of unstable identity and easy bypass in related path-based mandatory access control mechanisms.

[0225] Figure 5 This is a structural diagram of an access control device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0226] The acquisition module 52 is used to acquire the access path corresponding to the access request when an access request for the target file is detected, and to acquire the authoritative path in the extended attributes of the target file. The authoritative path is a baseline path that is pre-bound to the target file and is independent of the actual access path of the target file. It is used to characterize the legal path for which the target file is authorized to be accessed.

[0227] The judgment module 54 is used to determine whether the operation requested by the access request is allowed based on the access control rules, the subject attribute of the access request, the access type of the access request, the access path, and the consistency relationship with the authoritative path. The access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or an authoritative path.

[0228] It should be noted that the above Figure 5 The modules in can be program modules (e.g., a set of program instructions that implements a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0229] It should be noted that, Figure 5Preferred embodiments of the shown examples can be found in [reference needed]. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0230] Figure 6 A hardware block diagram of a computer terminal for implementing access control methods is shown. Figure 6 As shown, the computer terminal 60 may include one or more processors (shown as 602a, 602b, ..., 602n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 604 for storing data, and a transmission module 606 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 6 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, the computer terminal 60 may also include... Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown.

[0231] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 60. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0232] The memory 604 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the access control method in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 604, thereby implementing the aforementioned access control method. The memory 604 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 604 may further include memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 60 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0233] The transmission module 606 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 60. In one example, the transmission module 606 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 606 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0234] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 60.

[0235] It should be noted here that, in some optional embodiments, the above... Figure 6 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 6 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0236] It should be noted that, Figure 6 The computer terminal shown is used to execute Figure 1 The access control method shown above applies to this electronic device as well, and will not be repeated here.

[0237] This application also provides a non-volatile storage medium, which includes a stored program, wherein the program controls the device where the storage medium is located to execute the above access control method when it runs.

[0238] A non-volatile storage medium performs the following functions: Upon detecting an access request for a target file, it obtains the access path corresponding to the access request and the authoritative path in the extended attributes of the target file. The authoritative path is a baseline path pre-bound to the target file and independent of the actual access path of the target file, used to characterize the legal path for which the target file is authorized to be accessed. Based on the consistency relationship between the access control rules, the subject attributes of the access request, the access type of the access request, the access path, and the authoritative path, it determines whether the operation requested by the access request is allowed. The access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or an authoritative path.

[0239] This application also provides an electronic device, including a memory and a processor, wherein the processor is used to run a program stored in the memory, and the program executes the above-described access control method during runtime.

[0240] The processor is used to run a program that performs the following functions: upon detecting an access request for a target file, it obtains the access path corresponding to the access request and the authoritative path in the extended attributes of the target file, wherein the authoritative path is a baseline path pre-bound to the target file and independent of the actual access path of the target file, used to characterize the legal path for which the target file is authorized to be accessed; based on the consistency relationship between the access control rules, the subject attribute of the access request, the access type of the access request, the access path, and the authoritative path, it determines whether the operation requested by the access request is allowed, wherein the access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or an authoritative path.

[0241] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0242] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0243] In the above embodiments of this application, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, take necessary protective measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0244] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0245] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0246] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0247] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0248] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An access control method, characterized in that, include: Upon detecting an access request for a target file, the access path corresponding to the access request is obtained, and the authoritative path in the extended attributes of the target file is obtained. The authoritative path is a baseline path that is pre-bound to the target file and is independent of the actual access path of the target file, and is used to characterize the legitimate path for which the target file is authorized to be accessed. Based on the access control rules, the subject attribute of the access request, the access type of the access request, and the consistency relationship between the access path and the authoritative path, it is determined whether the operation requested by the access request is allowed. The access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or the authoritative path. The authoritative path is bound to the extended attributes of the target file through the following steps: The absolute path of the target file is normalized to obtain a normalized path; the existence of the target file is detected, and the existence of an authoritative path attribute for storing the authoritative path is detected in the extended attributes of the target file; if the target file exists and the authoritative path attribute does not exist in the extended attributes of the target file, the authoritative path attribute is created, and the normalized path is written as the authoritative path into the authoritative path attribute; if the target file does not exist, a pre-binding carrier corresponding to the target file is obtained, wherein the pre-binding carrier is a placeholder object pre-established before the target file is actually created to carry the authoritative path; the normalized path is written as the authoritative path into the extended attribute or pending attribute record corresponding to the pre-binding carrier; after obtaining the pre-binding carrier, it is detected whether the process performs a target operation on the target file, wherein the target operation is an operation that triggers the allocation or reuse of the inode of the target file; if the target operation is detected, during the allocation or reuse phase of the inode, the authoritative path in the pre-binding carrier is associated with the extended attributes of the target file.

2. The method according to claim 1, characterized in that, The absolute path of the target file is normalized to obtain a normalized path, including: Perform at least one of the following processes on the absolute path of the target file to obtain the normalized path: Separate consecutive paths in the absolute path of the target file into a single path separator; Eliminate the current directory component in the absolute path of the target file, and eliminate the parent directory component in the absolute path of the target file that can be parsed. The current directory component is used to represent the path component in the absolute path that refers to the current directory and does not change the actual direction the absolute path points to. The parent directory component is used to represent the path component in the absolute path that refers to the previous directory and is used to trace the absolute path back one level. Unify the directory separators in the absolute paths of the target files to a preset separator format; The absolute path of the target file is mapped in a standardized manner based on the controlled root directory or system root path. Based on the mount view information, the absolute path of the target file is converted into a globally consistent path representation, wherein the mount view information is information representing the file system mount relationship.

3. The method according to claim 1, characterized in that, The method further includes: During the allocation or reuse phase of the index node, if the same index node corresponds to multiple path entries, the path entry that serves as the authoritative path is determined in the following order: If the authoritative path attribute in the extended attributes of the target file corresponding to the inode has already registered an authoritative path, the registered authoritative path shall be used as the authoritative path. If the authoritative path is not registered in the authoritative path attribute of the extended attributes of the target file, the normalized path that was successfully written to the authoritative path attribute when the target file was first managed shall be used as the authoritative path. If two or more path entries simultaneously request to be the authoritative path, the path entry with the higher priority in the access control rule shall be the authoritative path. If the authoritative path cannot be uniquely determined, the target file is determined to be in a path identity conflict state, the operation requested by the access request for the target file is rejected, and the path identity conflict state is audited and recorded. The path identity conflict state is a state in which the path entry corresponding to the same index node cannot be uniquely determined as the authoritative path among multiple path entries.

4. The method according to claim 1, characterized in that, The method further includes: Upon receiving a deletion request for the target file, check whether the extended attributes of the target file contain an authoritative path attribute; If the authoritative path attribute is not present in the extended attributes of the target file, the target file is deleted according to the preset deletion process. If the authoritative path attribute exists in the extended attributes of the target file, the pre-bound carrier corresponding to the authoritative path of the target file is retained, and the authoritative path attribute is also retained. The method of retaining the pre-bound carrier includes any of the following: blocking the physical deletion of the target file; converting the target file into an empty content object before the deletion transaction corresponding to the deletion request is committed; and re-establishing the pre-bound carrier in the original path of the target file and restoring the authoritative path attribute after the target file is deleted.

5. The method according to claim 1, characterized in that, Based on the access control rules, the subject attributes of the access request, the access type of the access request, and the consistency relationship between the access path and the authoritative path, it is determined whether the operation requested by the access request is allowed, including: Detect whether the target file has path identity conflict, wherein the path identity conflict is that the same inode has two or more conflicting authoritative paths, or the authoritative path is missing and is defined as abnormal by the access control rule; If the target file does not have the path identity conflict, check whether the authoritative path in the extended attribute of the target file is consistent with the controlled path declared by the access control rule; If the authoritative path and the controlled path are the same, it is detected whether the access path belongs to the authorized access entry corresponding to the authoritative path, wherein the authorized access entry includes at least one of the authoritative path itself and the controlled alias entry allowed by the access control rules; If the access path belongs to the authorized access entry, the access control rules shall determine whether the subject attribute and the access type both meet the operation permissions for the authoritative path. If both the subject attribute and the access type satisfy the operation permissions for the authoritative path, the operation requested by the access request is allowed.

6. The method according to claim 5, characterized in that, The method further includes: If the authoritative path is not found in the extended attributes of the target file, the access request is processed according to a preset processing mode, wherein the preset processing mode is any one of default denial, default audit only, and compatibility allow; The determination result of whether to allow the operation requested by the access request is recorded, wherein, if the access path is inconsistent with the authoritative path, the access path, the authoritative path, and the audit event of the inconsistency between the access path and the authoritative path are recorded. If the authoritative path and the controlled path are inconsistent, the operation requested by the access request will be denied. If the access path does not belong to the authorized access entry point, the operation requested by the access request will be denied. If the subject attribute and / or the access type do not meet the operation permissions for the authoritative path, the operation requested by the access request shall be denied.

7. The method according to claim 1, characterized in that, Based on the access control rules, the subject attributes of the access request, the access type of the access request, and the consistency relationship between the access path and the authoritative path, it is determined whether the operation requested by the access request is allowed, including: Obtain the priority mode in the access control rule, wherein the access control rule declares a controlled path, and the controlled path is the path identity declared by the access control rule and controlled by the access control rule; the authoritative path corresponds to an authorized access entry, and the authorized access entry includes at least one of the authoritative path itself and the controlled alias entry allowed by the access control rule; When the priority mode indicates the first priority mode, if the authoritative path is consistent with the controlled path, the access path belongs to the authorized access entry, and the subject attribute and the access type satisfy the operation permissions for the authoritative path defined by the access control rules, the operation requested by the access request is allowed; otherwise, the operation requested by the access request is denied. If the priority mode indicates the second priority mode, and the authoritative path is missing or the access path is inconsistent with the authoritative path, the access request is audited and logged before the operation requested by the access request is allowed.

8. The method according to claim 7, characterized in that, The method further includes: When the priority mode indicates the third priority mode, if the access path is inconsistent with the authoritative path, after rejecting the operation requested by the access request, at least one of controlled relocation and alias registration is performed on the access request; wherein, the controlled relocation is the process of redirecting the access request to the authoritative path under controlled conditions, and the alias registration is the process of registering the access path as a controlled alias entry of the authoritative path; When the priority mode indicates the fourth priority mode, if the trusted subject meets the preset additional constraints, the trusted subject is allowed to perform path identity repair; wherein, the trusted subject is the subject that has been granted governance permissions by the access control rules, and the path identity repair is the process of correcting the authoritative path of the target file.

9. The method according to claim 1, characterized in that, The method further includes: In the case of the access request being a path migration operation, the movement of the directory entry of the target file and the update of the authoritative path in the extended attributes of the target file are processed as the same transaction, wherein the path migration operation is an operation that changes the path of the target file. If the file system where the target file resides supports a transaction mechanism or a log mechanism, the directory entry move and the authoritative path update are executed as the same atomic commit unit; If the file system where the target file is located does not support transaction mechanism and does not support log mechanism, the directory entry movement and the authoritative path update are executed according to the preset transaction process so that the directory entry movement and the authoritative path update take effect at the same time or do not take effect at the same time. The preset transaction process includes pre-checking the directory entry movement and the authoritative path update, retaining the old state, performing verification after commit, and rolling back when it fails. If the directory entry is moved successfully but the authoritative path update fails, the target file is put into an abnormal protection state, wherein the abnormal protection state includes at least one of the following: blocking the current operation from taking effect, rolling back the directory entry move, marking the target file as mismatched and rejecting subsequent access requests for the target file, and allowing only trusted repair processes to process the target file.

10. The method according to claim 1, characterized in that, The method further includes: If the target file is copied, imported, or restored, the target file will be processed according to the access control rules as follows: When the access control rule indicates an inheritance policy, the authoritative path of the source object from which the target file is copied is taken as the authoritative path of the target file. If the access control rule instructs a rebinding policy, a new authoritative path is bound to the target file; When the access control rule indicates a remanagement policy, the target file is identified as an object to be remanaged, and an authoritative path is determined for the target file after it is remanaged. When the access control rule indicates a trusted binding policy and the subject of the access request is a trusted subject, the trusted subject is allowed to bind an authoritative path to the target file, wherein the trusted subject is a subject granted governance permissions by the access control rule.

11. The method according to claim 1, characterized in that, The method further includes: When adding a new path entry to the target file, the authoritative path in the extended attributes of the target file remains unchanged. The method of adding the new path entry includes creating a hard link to the target file and presenting the target file through different mount points or different file system views. When an access request is initiated to the target file through the newly added path entry, the access path corresponding to the access request is obtained, the authoritative path is read from the extended attributes of the target file, and the operation requested by the access request is determined based on the consistency relationship between the access path and the authoritative path.

12. The method according to claim 1, characterized in that, The method further includes performing at least one of the following protection processes on the authoritative path attribute storing the authoritative path: Set the authoritative path attribute as an extended attribute under the protected namespace, wherein the authoritative path attribute is identified by a preset key value; The permission to modify the authoritative path attribute is set to only processes with preset management permissions, thus prohibiting user-mode processes from directly modifying the authoritative path attribute. Audit logs are created for the setting, modification, and deletion operations of the authoritative path attribute. The attribute value of the authoritative path attribute is appended with at least one of the following: verification information, version information, policy identifier, and integrity protection field.

13. An access control device, characterized in that, include: The acquisition module is used to acquire the access path corresponding to the access request when an access request for the target file is detected, and to acquire the authoritative path in the extended attributes of the target file, wherein the authoritative path is a baseline path that is pre-bound to the target file and is independent of the actual access path of the target file, and is used to characterize the legal path for which the target file is authorized to be accessed. The judgment module is used to determine whether to allow the operation requested by the access request based on the access control rules, the subject attribute of the access request, the access type of the access request, and the consistency relationship between the access path and the authoritative path. The access control rules are used to describe the types of operations allowed when a preset subject path accesses a preset object path or the authoritative path. The access control device is further configured to perform the following steps: normalize the absolute path of the target file to obtain a normalized path; detect whether the target file exists and detect whether there is an authoritative path attribute in the extended attributes of the target file for storing the authoritative path; if the target file exists and the authoritative path attribute does not exist in the extended attributes of the target file, create the authoritative path attribute and write the normalized path as the authoritative path into the authoritative path attribute; if the target file does not exist, obtain the pre-binding carrier corresponding to the target file, wherein the pre-binding carrier is a placeholder object pre-established before the target file is actually created to carry the authoritative path; write the normalized path as the authoritative path into the extended attribute or pending attribute record corresponding to the pre-binding carrier; after obtaining the pre-binding carrier, detect whether the process performs a target operation on the target file, wherein the target operation is an operation that triggers the allocation or reuse of the inode of the target file; if the target operation is detected, during the allocation or reuse phase of the inode, associate the authoritative path in the pre-binding carrier with the extended attributes of the target file.

14. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the access control method according to any one of claims 1 to 12.

15. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the non-volatile storage medium to perform the access control method according to any one of claims 1 to 12.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the access control method according to any one of claims 1 to 12.

Images