A dynamic role-based access control method and system based on a lustre file system

Abstract

The application belongs to the technical field of computer storage, and particularly relates to a dynamic role access control method and system based on a Lustre file system, which comprises a kernel space Lustre_rbac LSM module and a user space component, the LSM module intercepts a file operation request through a hook function, and extracts security context and resource information; a user space dynamic policy daemon combines real-time dynamic attributes and a policy rule library decision, and returns a result through Netlink. The system integrates Lustre semantic perception, policy cache optimization, hierarchical role inheritance and access audit mechanism, and realizes fine and dynamic permission control. The method completes access control through role configuration, request interception, information extraction, policy evaluation, decision execution and log recording. The application does not need to modify the Lustre kernel, has strong compatibility, is simple to deploy, considers safety and high performance, and is suitable for dynamic requirements of HPC scenes.

Description

Technical Field

[0001] This invention belongs to the field of computer storage technology, and in particular relates to a dynamic role-based access control method and system based on the Lustre file system. Background Technology

[0002] With the rapid development of high-performance computing (HPC) and big data technologies, data volume is growing exponentially, placing higher demands on the capacity, performance, and security of storage systems. Lustre file system, as an open-source parallel distributed file system, has become a core storage solution for large-scale cluster computing scenarios due to its high bandwidth and high concurrency characteristics, and is widely used in key areas such as scientific computing, artificial intelligence training, and industrial simulation.

[0003] In practical applications of the Lustre file system, access control is a core element in ensuring data security. The existing native permission model of the Lustre file system is primarily based on traditional POSIX permissions and Access Control Lists (ACLs). This model employs a three-tiered permission partitioning approach: User-Group-Other (UGO). This coarse-grained permission allocation only enables simple batch permission assignment and cannot meet the differentiated permission needs of different users in complex project teams. Furthermore, its permission allocation method is static, requiring manual configuration adjustments by administrators for permission changes. This makes it difficult to adapt to dynamically changing computing task scenarios—for example, when the participants in a computing task and data access requirements dynamically adjust with project phases, the static permission model cannot respond in real time, easily leading to issues of excessive or insufficient permissions, thus affecting data security or task execution efficiency. In addition, the native permission model's permission decisions rely solely on user identity and resource ownership, lacking awareness of the access context. It cannot incorporate dynamic factors such as process type, task stage, and system status for permission determination, further limiting the flexibility and accuracy of its security protection.

[0004] To address the secure access issues of general-purpose file systems, the Linux kernel provides the Linux Security Module (LSM) framework, which supports the implementation of security policies as loadable kernel modules and performs security checks on critical paths of system calls. Currently, mainstream LSM implementations include SELinux and AppArmor. While these solutions possess strong security control capabilities, they have significant limitations in the application scenarios of the Lustre file system. First, the policy configuration is highly complex. Taking SELinux as an example, it uses a dedicated policy language, which makes the configuration logic cumbersome and the management and maintenance costs high, making it difficult to promote and apply in HPC environments. Second, the strategy has a static configuration feature. Traditional LSM strategies are usually loaded when the system starts up. During operation, it is difficult to adjust the strategy rules according to dynamic states such as system load and task priority, which cannot adapt to the dynamic computing scenarios corresponding to the Lustre file system. Third, it lacks native integration capabilities with the Lustre file system. Existing LSM solutions do not fully consider the special semantics of Lustre, such as striped storage, multi-data server (MDS) collaboration, and object storage server (OSS) data distribution. It is difficult to directly apply complex, role-based dynamic policies, resulting in poor security control effects in the Lustre file system.

[0005] Therefore, how to build an access control system based on the LSM framework, adapted to the characteristics of the Lustre file system, and with both flexibility and dynamism, to solve the problems of coarse permission granularity, rigid static configuration, lack of context awareness, and insufficient Lustre semantic adaptation in existing technologies, has become a technical challenge that urgently needs to be solved in the field of high-performance computing storage. Summary of the Invention

[0006] The purpose of this invention is to provide a dynamic role-based access control method and system based on the Lustre file system, in order to build an access control system based on the LSM framework, adapted to the characteristics of the Lustre file system, and with both flexibility and dynamism, solving the problems of coarse permission granularity, rigid static configuration, lack of context awareness and insufficient Lustre semantic adaptation in the prior art.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: Firstly, a dynamic role access control system based on the Lustre file system is provided, including a kernel space component and a user space component. The kernel space component is the Lustre_rbac LSM module, and the user space component includes a dynamic policy daemon, a policy and attribute management service module, and a management command line tool. The Lustre_rbac LSM module registers a set of LSM hook functions for file system operations, including file operation permission check hooks, file open and operation hooks, extended attribute operation hooks, and task security context hooks. The dynamic policy daemon includes a policy decision point, a context sensor, a policy engine, and a communication interface. The strategy and attribute management service module includes a role library, an attribute library, a strategy rule library, and a tag management module; The Lustre_rbac LSM module intercepts file system operation requests initiated by Lustre clients through the LSM hook function, extracts the security context and resource information associated with the request, and sends it to the dynamic policy daemon. The dynamic policy daemon combines real-time dynamic attributes and policy rule base to make a decision and returns the decision result to the Lustre_rbac LSM module, which then performs the allow or deny operation.

[0008] Preferably, when a Lustre client initiates a system call, the VFS layer triggers the LSM hook function, which performs the following operations: Extracting security context: Extracting user identity and role tags from the process's task_struct and security credentials; Collect request information: Obtain the inode information of the target file and extract resource tags from it; Initiate a policy query: Encapsulate the user, role, operation, resource, and resource tag into a query request and send it to the dynamic policy daemon via a Netlink socket; Decision execution: Synchronously wait for the decision result of the dynamic policy daemon, and return 0 or -EACCES based on the returned ALLOW or DENY.

[0009] Preferably, the execution process of the dynamic policy daemon is as follows: The strategy decision point receives query requests from the Lustre_rbac LSM module through the communication interface; The context sensor collects at least one dynamic attribute from system time, system load, network information, and GPU utilization in real time. The strategy engine combines the user, role, operation, resource, and resource tag in the query request with the dynamic attributes collected by the context perceiver, queries the rules in the strategy rule base for logical evaluation, and generates a decision result. The communication interface returns the decision results to the Lustre_rbac LSM module via a Netlink socket.

[0010] Preferably, the working mechanism of the strategy and attribute management service module is set as follows: The role library defines and manages roles, and associates role tags with users / processes through extended attributes or the security field of the LSM; The attribute library stores and manages various dynamic context attributes collected by the context perceiver; The policy rule base stores role-based dynamic policies; The label management module provides tools to set security labels for Lustre files and directories; The management command-line tool is used by system administrators to manage roles, dynamic policies, and security labels.

[0011] Preferably, it also includes a Lustre semantic awareness adaptation mechanism. The Lustre semantic awareness adaptation mechanism is designed for the striped storage, multi-MDS collaboration, and OSS data distribution characteristics of the Lustre file system. When the LSM hook function extracts resource information, it additionally obtains the file striping parameters, the MDS node identifier, and the list of associated OSS nodes. The policy engine uses the file striping parameters, the MDS node identifier, and the list of associated OSS nodes as additional evaluation factors during logical evaluation.

[0012] Preferably, a policy caching optimization mechanism is also set up, wherein after the dynamic policy daemon generates the decision result, it stores the query request, the corresponding decision result, and the dynamic attribute combination as a cache item in the cache space; When the policy decision point receives the same query request again, the policy engine first queries the cache space: If a valid cached item exists, the corresponding decision result is returned directly. If no valid cached item exists or the cached item is invalid, the dynamic attribute collection and rule query process will be executed.

[0013] Preferably, a hierarchical role inheritance mechanism is also set up, in which a role hierarchy is set in the role library, and a higher-level role automatically inherits the permissions of a lower-level role, and supports configuring exclusive permissions for a higher-level role; When extracting role tags, the LSM hook function simultaneously extracts role hierarchy information. When performing logical evaluation, the strategy engine combines the role hierarchy relationship with dynamic strategies to determine permissions.

[0014] Preferably, an access behavior auditing mechanism is also set up. After executing the decision, the Lustre_rbac LSM module encapsulates the user identity, role tag, operation type, resource information, resource tag, dynamic attributes, decision result, and operation timestamp into an audit log. The user space component also includes an audit log storage module, which receives and stores the audit logs and supports log querying and exporting by user, role, resource, time range, and decision result.

[0015] Secondly, a dynamic role-based access control method based on the Lustre file system is provided, applicable to any of the dynamic role-based access control systems based on the Lustre file system described above, comprising the following steps: S1: The system administrator defines roles in the role library through the management command-line tool, assigns target roles to users, sets security labels for Lustre target files / directories through the label management module, and configures dynamic policies in the policy rule library; S2: The Lustre client initiates a file system operation request, and the VFS layer triggers the corresponding LSM hook function in the Lustre_rbac LSM module; S3: The LSM hook function extracts user identity and role tags from the process's task_struct and security credentials, extracts resource tags from the target file's inode information, and if the system has a Lustre semantic awareness adaptation mechanism, it additionally obtains file striping parameters, the identifier of the MDS node to which it belongs, and the list of associated OSS nodes. S4: The LSM hook function encapsulates the user identity, role tag, operation type, resource information, resource tag, as well as optional file striping parameters, MDS node identifier, and associated OSS node list into a query request, and sends it to the dynamic policy daemon process through a Netlink socket; S5: The dynamic policy daemon receives a query request at its policy decision point. The context sensor collects dynamic attributes in real time. If the system has a policy caching optimization mechanism, the policy engine first queries the cache space. If there is a valid cache item, it directly obtains the decision result. Otherwise, it executes step S6. S6: The strategy engine combines the relevant information in the query request with the collected dynamic attributes. If the system has a hierarchical role inheritance mechanism, it synchronously combines the role hierarchy relationship, queries the dynamic strategy in the strategy rule base for logical evaluation, and generates a decision result. S7: The dynamic policy daemon returns the decision result to the LSM hook function through the Netlink socket. If the system has a policy caching optimization mechanism, the query request and the corresponding decision result and dynamic attribute are stored in the cache space. S8: The LSM hook function performs operations based on the decision result. If the decision result is ALLOW, then the file system operation request is allowed to be sent to the Lustre MDS / OSS backend. If the decision result is DENY, then return -EACCES; S9: If the system has an access behavior auditing mechanism, the LSM hook function generates an audit log and sends it to the audit log storage module for storage after executing the decision.

[0016] Preferably, the dynamic strategy configured in step S1 includes: Users with the role of data_scientist are only allowed to write data to the Lustre directory with the training_zone security label when the global GPU utilization is below a preset threshold. The dynamic attributes collected by the context awareness device in step S5 include global GPU utilization; In step S6, the policy engine determines whether the user role is data_scientist, whether the operation type is write, whether the resource label is training_zone, and whether the global GPU utilization is lower than a preset threshold. If all conditions are met, an ALLOW decision result is generated; otherwise, a DENY decision result is generated.

[0017] The beneficial effects of this invention include: 1. Fine-grained access control to adapt to complex scenarios: A role library is used to define and manage roles, associating role tags with users / processes. Security tags are also set for Lustre files and directories, constructing a fine-grained "role-resource" access control system. Access decisions not only rely on user identity and role but also combine operation type, resource tags, and dynamic attributes. This breaks through the limitations of the traditional POSIX access control model's coarse-grained approach, meeting the differentiated access needs of different users in complex project teams and achieving precise control over data access.

[0018] 2. Dynamically Adjustable Policies, Responding to Real-Time System Status: Employing an architecture that coordinates decision-making between the kernel-space LSM module and the user-space dynamic policy daemon, a context-aware system collects dynamic attributes such as system time, load, network information, and GPU utilization in real time. The policy engine then combines these real-time attributes with the policy rule base for logical evaluation. Compared to the static policy configuration of traditional LSMs, policy decisions are executed in real-time on each access, enabling dynamic responses to changes in system status and adjustments to task requirements.

[0019] 3. Deep Adaptation to Lustre Features, Ensuring System Compatibility and Control Effectiveness: Through the Lustre semantic-aware adaptation mechanism, key information such as file striping parameters, MDS node identifiers, and associated OSS node lists are additionally obtained during resource information extraction, taking into account the native characteristics of the Lustre file system, such as striped storage, multi-MDS collaboration, and OSS data distribution. This information is used as an additional factor in policy evaluation. This solves the problem of insufficient support for Lustre's special semantics in existing LSM solutions, ensuring that access control policies can adapt to the underlying architecture of Lustre and achieve precise and effective security control without affecting the original performance of the Lustre file system.

[0020] 4. High performance and low overhead, suitable for large-scale computing scenarios: Kernel space and user space communicate via efficient Netlink sockets, significantly reducing cross-space communication overhead compared to traditional system calls. Simultaneously, the policy caching optimization mechanism caches generated decision results and associated information, allowing subsequent identical query requests to directly reuse cached results, avoiding redundant attribute collection and rule evaluation processes and significantly improving decision-making efficiency. This ensures that even under high-concurrency file access requests in large-scale cluster computing scenarios, this invention maintains low latency and high throughput performance, without compromising the inherent advantages of the Lustre file system.

[0021] 5. Non-intrusive deployment, reducing operation and maintenance costs: Deployment requires no modification to the Lustre kernel code; simply loading the Lustre_rbacLSM module and running the userspace daemon completes the process. It has no intrusive impact on the existing Lustre system architecture and operation, making the deployment process simple and efficient. Furthermore, through the management command-line tool, system administrators can easily manage roles, configure policies, and set tags. Compared to complex LSM solutions like SELinux, this significantly reduces the difficulty of policy configuration and system maintenance, improving management efficiency.

[0022] 6. Layered Security Protection for Enhanced Data Security: This invention is built on the Linux LSM framework, with security controls deeply embedded in the operating system kernel. It can intercept access requests at critical paths of system calls, preventing bypass by user-space programs and providing kernel-level security protection. Simultaneously, the hierarchical role inheritance mechanism achieves orderly inheritance and customized configuration of permissions by setting hierarchical role relationships, simplifying permission management logic while ensuring the standardization of permission allocation. The access behavior auditing mechanism fully records key information such as user identity, role, operation type, and decision results, supporting log querying and export, facilitating security auditing and abnormal behavior tracing, further strengthening the data security protection system. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the architecture of the dynamic role access control system based on the Lustre file system of the present invention. Detailed Implementation

[0024] The following is in conjunction with the appendix Figure 1 The present invention will be further described in detail below: Example 1 See appendix Figure 1As shown, a dynamic role access control system based on the Lustre file system is characterized by comprising a kernel space component and a user space component. The kernel space component is a Lustre_rbac LSM module, and the user space component includes a dynamic policy daemon, a policy and attribute management service module, and a management command-line tool.

[0025] The Lustre_rbac LSM module registers a set of LSM hook functions for file system operations, including file operation permission check hooks, file open and operation hooks, extended attribute operation hooks, and task security context hooks.

[0026] The dynamic policy daemon includes a policy decision point, a context sensor, a policy engine, and a communication interface.

[0027] The strategy and attribute management service module includes a role library, an attribute library, a strategy rule library, and a tag management module; The Lustre_rbac LSM module intercepts file system operation requests initiated by Lustre clients through the LSM hook function, extracts the security context and resource information associated with the request, and sends it to the dynamic policy daemon. The dynamic policy daemon combines real-time dynamic attributes and policy rule base to make a decision and returns the decision result to the Lustre_rbac LSM module, which then performs the allow or deny operation.

[0028] The specific implementation of the LSM hook function is as follows: static struct security_operations Lustre_rbac_ops = {.name = "Lustre_rbac", / * File operation permission check / .file_permission = rbac_file_permission, .inode_permission = rbac_inode_permission, .inode_create = rbac_inode_create, .inode_unlink = rbac_inode_unlink, .inode_rename = rbac_inode_rename, .inode_mkdir = rbac_inode_mkdir, .inode_rmdir = rbac_inode_rmdir, .inode_symlink = rbac_inode_symlink, / File Opening and Manipulation / .file_open = rbac_file_open, .file_ioctl = rbac_file_ioctl, .file_mmap = rbac_file_mmap, / Extended Attribute Operations / .inode_setxattr = rbac_inode_setxattr, .inode_getxattr = rbac_inode_getxattr, .inode_removexattr = rbac_inode_removexattr, / task security context* / .task_alloc = rbac_task_alloc,.task_free = rbac_task_free,}; When a Lustre client initiates a system call, the VFS layer triggers the LSM hook function, which performs the following operations: Extracting security context: Extracting user identity and role tags from the process's task_struct and security credentials; Collect request information: Obtain the inode information of the target file and extract resource tags from it; Initiate a policy query: Encapsulate the user, role, operation, resource, and resource tag into a query request and send it to the dynamic policy daemon via a Netlink socket; Decision execution: Synchronously wait for the decision result of the dynamic policy daemon, and return 0 or -EACCES based on the returned ALLOW or DENY.

[0029] Example 2 Based on Example 1, the execution process of the dynamic policy daemon is as follows: The strategy decision point receives query requests from the Lustre_rbac LSM module through the communication interface; The context sensor collects at least one dynamic attribute from system time, system load, network information, and GPU utilization in real time. The strategy engine combines the user, role, operation, resource, and resource tag in the query request with the dynamic attributes collected by the context perceiver, queries the rules in the strategy rule base for logical evaluation, and generates a decision result. The communication interface returns the decision results to the Lustre_rbac LSM module via a Netlink socket.

[0030] The working mechanism of the strategy and attribute management service module is set as follows: The role library defines and manages roles, and associates role tags with users / processes through extended attributes or the security field of the LSM; The attribute library stores and manages various dynamic context attributes collected by the context perceiver; The policy rule base stores role-based dynamic policies, and the format of the dynamic policy is "IF (role==[role identifier] AND [dynamic attribute condition] AND operation==[operation type] AND resource.label==[resource label identifier]) THEN [decision result]"; The label management module provides tools to set security labels for Lustre files and directories; The management command-line tool is used by system administrators to manage roles, dynamic policies, and security labels.

[0031] It also includes a Lustre semantic awareness adaptation mechanism. This mechanism is designed for the striped storage, multi-MDS collaboration, and OSS data distribution characteristics of the Lustre file system. When the LSM hook function extracts resource information, it additionally obtains the file striping parameters, the MDS node identifier, and the list of associated OSS nodes. The policy engine uses the file striping parameters, the MDS node identifier, and the list of associated OSS nodes as additional evaluation factors during logical evaluation.

[0032] A policy caching optimization mechanism is also set up. After generating the decision result, the dynamic policy daemon process stores the query request, the corresponding decision result, and the dynamic attribute combination as a cache item in the cache space. When the policy decision point receives the same query request again, the policy engine first queries the cache space. If there is a valid cache item, it directly returns the corresponding decision result. If there is no valid cache item or the cache item is invalid, the dynamic attribute collection and rule query process is executed.

[0033] Example 3 Based on Embodiment 1 or Embodiment 2, a hierarchical role inheritance mechanism is also set up. The role library sets up a role hierarchy, and the superior role automatically inherits the permissions of the subordinate role. It also supports configuring exclusive permissions for the superior role. When the LSM hook function extracts role tags, it simultaneously extracts role hierarchy information. When the strategy engine evaluates the logic, it combines the role hierarchy and dynamic strategy to determine permissions.

[0034] An access behavior auditing mechanism is also set up. After executing the decision, the Lustre_rbac LSM module encapsulates the user identity, role tag, operation type, resource information, resource tag, dynamic attributes, decision result, and operation timestamp into an audit log. The user space component also includes an audit log storage module, which receives and stores the audit logs and supports log querying and exporting by user, role, resource, time range, and decision result.

[0035] A dynamic role-based access control method based on the Lustre file system, applying any one of the dynamic role-based access control systems based on the Lustre file system, includes the following steps: S1: The system administrator defines roles in the role library through the management command-line tool, assigns target roles to users, sets security labels for Lustre target files / directories through the label management module, and configures dynamic policies in the policy rule library; S2: The Lustre client initiates a file system operation request, and the VFS layer triggers the corresponding LSM hook function in the Lustre_rbac LSM module; S3: The LSM hook function extracts user identity and role tags from the process's task_struct and security credentials, extracts resource tags from the target file's inode information, and if the system has a Lustre semantic awareness adaptation mechanism, it additionally obtains file striping parameters, the identifier of the MDS node to which it belongs, and the list of associated OSS nodes. S4: The LSM hook function encapsulates the user identity, role tag, operation type, resource information, resource tag, as well as optional file striping parameters, MDS node identifier, and associated OSS node list into a query request, and sends it to the dynamic policy daemon process through a Netlink socket; S5: The dynamic policy daemon receives a query request at its policy decision point. The context sensor collects dynamic attributes in real time. If the system has a policy caching optimization mechanism, the policy engine first queries the cache space. If there is a valid cache item, it directly obtains the decision result. Otherwise, it executes step S6. S6: The strategy engine combines the relevant information in the query request with the collected dynamic attributes. If the system has a hierarchical role inheritance mechanism, it synchronously combines the role hierarchy relationship, queries the dynamic strategy in the strategy rule base for logical evaluation, and generates a decision result. S7: The dynamic policy daemon returns the decision result to the LSM hook function through the Netlink socket. If the system has a policy caching optimization mechanism, the query request and the corresponding decision result and dynamic attribute are stored in the cache space. S8: The LSM hook function performs operations based on the decision result. If the decision result is ALLOW, the file system operation request is allowed to be sent to the Lustre MDS / OSS backend; if the decision result is DENY, -EACCES is returned. S9: If the system has an access behavior auditing mechanism, the LSM hook function generates an audit log and sends it to the audit log storage module for storage after executing the decision.

[0036] The dynamic policies configured in step S1 include: Users with the role of data_scientist are only allowed to write data to the Lustre directory with the training_zone security label when the global GPU utilization is below a preset threshold. The dynamic attributes collected by the context awareness device in step S5 include global GPU utilization; In step S6, the policy engine determines whether the user role is data_scientist, whether the operation type is write, whether the resource label is training_zone, and whether the global GPU utilization is lower than a preset threshold. If all conditions are met, an ALLOW decision result is generated; otherwise, a DENY decision result is generated.

[0037] Example 4 Based on Embodiment 1, Embodiment 2, or Embodiment 3, the implementation process of this aspect is illustrated using specific scenarios: Implementation environment configuration: Hardware environment: A high-performance computing (HPC) cluster with Lustre file system is deployed, including 3 Meta DataServer (MDS) nodes (MDS-1, MDS-2, MDS-3), 10 Object Storage Server (OSS) nodes (OSS-1 to OSS-10), and 50 Lustre client nodes. The cluster is equipped with a GPU resource pool (including 20 GPU cards).

[0038] Software environment: Linux kernel version 5.14 and above (supporting LSM framework extension), Lustre file system version 2.15. The Lustre_rbacLSM module of this invention has been compiled into a loadable kernel module. The user space components include a dynamic policy daemon, a policy and attribute management service module, a management command line tool, and an audit log storage module.

[0039] Pre-configured resources: The Lustre file system contains a critical business directory / Lustre / production_data / (storing core production data, with striping parameters "stripes=8, stripe_size=1MB") and a training data directory / Lustre / training_data / (storing model training datasets, with striping parameters "stripes=4, stripe_size=2MB"). The two directories are associated with OSS node lists [OSS-1~OSS-4] and [OSS-5~OSS-8], respectively, and belong to MDS nodes MDS-1 and MDS-2, respectively.

[0040] System initialization configuration: Role definition and assignment: The system administrator defines a three-level role hierarchy in the role library using the management command-line tool Lustre_rbac_cli. Basic role: data_visitor, permissions: only allowed to read non-sensitive files in the / Lustre / training_data / directory; The intermediate role, data_scientist, inherits the permissions of data_visitor, with additional permissions: write data to the / Lustre / training_data / directory and read files from public subdirectories under the / Lustre / production_data / directory; The advanced role admin_scientist inherits the permissions of data_scientist, with additional permissions: modify permissions of the / Lustre / training_data / directory and read all files in the / Lustre / production_data / directory.

[0041] Assign the role data_scientist to user Alice and the role admin_scientist to user Bob. The role labels are associated with the user process through the security field of the LSM.

[0042] Resource tag settings: Administrators can set security tags for the Lustre directory through the tag management module: Set the label `production_zone` for ` / Lustre / production_data / `, with sensitivity set to `restricted`. Set the label training_zone for / Lustre / training_data / with sensitivity: confidential.

[0043] Dynamic policy configuration: Configure the following core policies in the policy rule base: Strategy 1: IF(user.role=="data_scientist"ANDoperation=="write"ANDresource.label=="training_zone"ANDsystem.gpu_util<60ANDresource.stripe_size==2MBANDresource.mds_id=="MDS-2"ANDresource.oss_list [OSS-5~OSS-8])THENALLOW; Strategy 2: IF(user.role=="admin_scientist"ANDoperation=="read"ANDresource.label=="production_zone"ANDsystem.load<70)THENALLOW; Strategy 3: IF(user.role=="data_scientist"ANDoperation=="read"ANDresource.label=="production_zone")THENDENY.

[0044] Scenario 1: Alice performs the training data writing operation: Initiate an operation request: Alice starts an AI training task on the client node. The process inherits its role label data_scientist. This task attempts to write the model file model_v2.ckpt to the / Lustre / training_data / directory.

[0045] Hook functions extract information: The Lustre client initiates a system call to write a file, and the VFS layer triggers the inode_create and file_open hook functions of the Lustre_rbacLSM module: Extract the security context: user identity Alice, role label data_scientist, role level (intermediate, inheriting data_visitor permissions); Collect resource information: target file inode information, resource tag training_zone; Because the system has a Lustre semantic awareness adaptation mechanism, it additionally obtains the file striping parameters (stripes=4, stripe_size=2MB), the identifier of the MDS node (MDS-2), and the list of associated OSS nodes (OSS-5~OSS-8).

[0046] Install query request: The hook function encapsulates "user Alice, role data_scientist, operation write, resource / Lustre / training_data / model_v2.ckpt, resource tag training_zone, striping parameters stripes=4, stripe_size=2MB, MDS identifier MDS-2, OSS list OSS-5~OSS-8" into a query request, and sends it to the dynamic policy daemon via a Netlink socket.

[0047] Receiving requests and cache queries: The dynamic policy daemon receives query requests at its policy decision point, and the context sensor collects dynamic attributes in real time: the current global GPU utilization is 55%, and the system load is 40%. Because the system has a policy caching optimization mechanism, the policy engine first queries the cache space. If no valid cached entry for the query is found, the policy logic is then evaluated. The strategy engine combines query request information with dynamic attributes and associates them with role hierarchy relationships. `data_scientist` inherits `data_visitor` permissions and queries the strategy rule base. Matching Strategy 1: If the user role is data_scientist, the operation is write, the resource label is training_zone, the GPU utilization rate is 55% < 60%, the strip size is 2MB, the MDS identifier is MDS-2, and the OSS list contains OSS-5 to OSS-8, and all conditions are met, the decision result ALLOW is generated.

[0048] Return results and cache storage: The dynamic policy daemon returns the ALLOW decision result to the LSM hook function through the Netlink socket, and stores "query request + decision result ALLOW + dynamic attributes (GPU utilization 55%, system load 40%)" as a cache item in the cache space, with the cache validity period set to 300 seconds.

[0049] Decision execution: The LSM hook function receives an ALLOW result, allowing the file write request to be sent to the LustreMDS-2 node and OSS-5~OSS-8 nodes, and the write operation is executed successfully.

[0050] Generate audit logs: After the hook function executes the decision, it encapsulates the audit log: "User Alice, Role data_scientist, Operation write, Resource / Lustre / training_data / model_v2.ckpt, Resource tag training_zone, Dynamic attributes (GPU utilization 55%, System load 40%), Decision result ALLOW, Timestamp 2024-05-2014:32:15", and sends it to the audit log storage module for storage.

[0051] Scenario 2: Alice repeatedly performs the same write operation (triggering cache optimization): Alice's training task, within the 300-second cache validity period, attempts to write the file model_v3.ckpt to the / Lustre / training_data / directory again. The operation process is as follows: In the same scenario, the hook function extracts the same information and encapsulates the query request; After receiving a request, the dynamic policy daemon queries the cache space. If a valid cached item is found, the query request is consistent, the cache has not expired, and the ALLOW decision result is obtained directly, skipping the dynamic attribute collection and rule evaluation process. The system returns ALLOW immediately, the write operation is executed quickly, and a new audit log is generated at the same time. The cached items are not updated (because the dynamic attributes do not change significantly).

[0052] Scenario 3: Alice attempts to read production data (triggers permission denial): Alice's training task attempts to read the file core_config.cfg in the / Lustre / production_data / directory. The operation process is as follows: The hook function extracts user Alice, role data_scientist, operation read, resource tag production_zone, striping parameters stripes=8, stripe_size=1MB, MDS identifier MDS-1, OSS list OSS-1~OSS-4, encapsulates the request and sends it to the daemon process. The context aware collector collects dynamic attributes: system load 65%, GPU utilization 45%, no valid entries in the cache; The strategy engine matches strategy 3, the user role is data_scientist and the operation read corresponds to the resource label production_zone, and generates the decision result DENY; The daemon returns a DENY result, and the LSM hook function returns -EACCES to the process, indicating that the read operation failed. Generate an audit log to record the "Decision Result DENY" and related operation information.

[0053] Scenario 4: Bob performs a production data read operation (advanced role permission adaptation): Bob initiates a read operation on the client node to read / Lustre / production_data / core_config.cfg, as follows: The hook function extracts user Bob, role admin_scientist, role level (high-level, inheriting data_scientist permissions), operation read, resource tag production_zone, and Lustre semantic information; The context-aware sensor collects dynamic attributes: system load 68% < 70%; The strategy engine matches strategy 2, with user role as admin_scientist, operation as read, resource tag as production_zone, and system load as 68% < 70%. If the conditions are met, an ALLOW result is generated. The read request was sent to MDS-1 and OSS-1~OSS-4 nodes, and the operation was successful. The audit log records Bob's access behavior and the basis for his decisions.

[0054] Audit log query: System administrators can use the query function of the audit log storage module to filter logs by "role=data_scientist" and "decision result=DENY" to quickly locate the operation records in which Alice attempted to read production data. The logs contain complete operation context, dynamic attributes and decision basis, and can be exported to CSV format for generating security audit reports.

[0055] In summary, the dynamic role-based access control method and system based on the Lustre file system provided by this invention, based on the Lustre dynamic access control module structure of the LSM framework, proposes a novel system architecture. It intercepts Lustre file operations by implementing a dedicated LSM module in the kernel and coordinates decision-making with a user-space policy daemon. This is the fundamental architectural innovation for all subsequent functions. The kernel-user-space dynamic policy decision-making mechanism based on Netlink communication protects the workflow of communication between the kernel module and the user daemon through the efficient Netlink mechanism. When an LSM hook is triggered, it does not make its own decision but sends the request context to user space in real time. The daemon integrates dynamic attributes (such as time and system load) and returns a dynamic decision result based on the latest policy. The integrated "role-attribute" security label management and application for Lustre protects the "label" system necessary for dynamic control. Specifically, this includes: associating "role" labels with the security context of a process; associating "resource" labels with Lustre files and directories; and extracting and applying these two types of labels during decision-making.

Claims

1. A dynamic role-based access control system based on the Lustre file system, characterized in that, It includes kernel space components and user space components. The kernel space component is the Lustre_rbac LSM module, and the user space component includes a dynamic policy daemon, a policy and attribute management service module, and a management command-line tool. The Lustre_rbac LSM module registers a set of LSM hook functions for file system operations, including file operation permission check hooks, file open and operation hooks, extended attribute operation hooks, and task security context hooks. The dynamic policy daemon includes a policy decision point, a context sensor, a policy engine, and a communication interface. The strategy and attribute management service module includes a role library, an attribute library, a strategy rule library, and a tag management module; The Lustre_rbac LSM module intercepts file system operation requests initiated by Lustre clients through the LSM hook function, extracts the security context and resource information associated with the request, and sends it to the dynamic policy daemon. The dynamic policy daemon combines real-time dynamic attributes and policy rule base to make a decision and returns the decision result to the Lustre_rbac LSM module, which then performs the allow or deny operation.

2. The dynamic role access control system based on the Lustre file system according to claim 1, characterized in that, When a Lustre client initiates a system call, the VFS layer triggers the LSM hook function, which performs the following operations: Extracting security context: Extracting user identity and role tags from the process's task_struct and security credentials; Collect request information: Obtain the inode information of the target file and extract resource tags from it; Initiate a policy query: Encapsulate the user, role, operation, resource, and resource tag into a query request and send it to the dynamic policy daemon via a Netlink socket; Decision execution: Synchronously wait for the decision result of the dynamic policy daemon, and return 0 or -EACCES based on the returned ALLOW or DENY.

3. A dynamic role-based access control system based on the Lustre file system according to claim 1, characterized in that, The execution process of the dynamic policy daemon is as follows: The strategy decision point receives query requests from the Lustre_rbac LSM module through the communication interface; The context sensor collects at least one dynamic attribute from system time, system load, network information, and GPU utilization in real time. The strategy engine combines the user, role, operation, resource, and resource tag in the query request with the dynamic attributes collected by the context perceiver, queries the rules in the strategy rule base for logical evaluation, and generates a decision result. The communication interface returns the decision results to the Lustre_rbac LSM module via a Netlink socket.

4. A dynamic role-based access control system based on the Lustre file system according to claim 3, characterized in that, The working mechanism of the strategy and attribute management service module is set as follows: The role library defines and manages roles, and associates role tags with users / processes through extended attributes or the security field of the LSM; The attribute library stores and manages various dynamic context attributes collected by the context perceiver; The policy rule base stores role-based dynamic policies; The label management module provides tools to set security labels for Lustre files and directories; The management command-line tool is used by system administrators to manage roles, dynamic policies, and security labels.

5. A dynamic role-based access control system based on the Lustre file system according to claim 4, characterized in that, It also includes a Lustre semantic awareness adaptation mechanism. This mechanism is designed for the striped storage, multi-MDS collaboration, and OSS data distribution characteristics of the Lustre file system. When the LSM hook function extracts resource information, it additionally obtains the file striping parameters, the MDS node identifier, and the list of associated OSS nodes. The policy engine uses the file striping parameters, the MDS node identifier, and the list of associated OSS nodes as additional evaluation factors during logical evaluation.

6. A dynamic role-based access control system based on the Lustre file system according to claim 5, characterized in that, A policy caching optimization mechanism is also set up. After generating the decision result, the dynamic policy daemon process stores the query request, the corresponding decision result, and the dynamic attribute as a cache item in the cache space. When the policy decision point receives the same query request again, the policy engine first queries the cache space: If a valid cached item exists, the corresponding decision result is returned directly. If no valid cached item exists or the cached item is invalid, the dynamic attribute collection and rule query process will be executed.

7. A dynamic role access control system based on the Lustre file system according to claim 1, characterized in that, A hierarchical role inheritance mechanism is also set up. The role library sets up a hierarchical relationship between roles. The upper-level role automatically inherits the permissions of the lower-level role, and it also supports configuring exclusive permissions for the upper-level role. When extracting role tags, the LSM hook function simultaneously extracts role hierarchy information. When performing logical evaluation, the strategy engine combines the role hierarchy relationship with dynamic strategies to determine permissions.

8. A dynamic role access control system based on the Lustre file system according to claim 7, characterized in that, An access behavior auditing mechanism is also set up. After executing the decision, the Lustre_rbac LSM module encapsulates the user identity, role tag, operation type, resource information, resource tag, dynamic attributes, decision result, and operation timestamp into an audit log. The user space component also includes an audit log storage module, which receives and stores the audit logs and supports log querying and exporting by user, role, resource, time range, and decision result.

9. A dynamic role-based access control method based on the Lustre file system, applied to the dynamic role-based access control system based on the Lustre file system as described in any one of claims 1-8, characterized in that, Includes the following steps: S1: The system administrator defines roles in the role library through the management command-line tool, assigns target roles to users, sets security labels for Lustre target files / directories through the label management module, and configures dynamic policies in the policy rule library; S2: The Lustre client initiates a file system operation request, and the VFS layer triggers the corresponding LSM hook function in the Lustre_rbac LSM module; S3: The LSM hook function extracts user identity and role tags from the process's task_struct and security credentials, extracts resource tags from the target file's inode information, and if the system has a Lustre semantic awareness adaptation mechanism, it additionally obtains file striping parameters, the identifier of the MDS node to which it belongs, and the list of associated OSS nodes. S4: The LSM hook function encapsulates the user identity, role tag, operation type, resource information, resource tag, as well as optional file striping parameters, MDS node identifier, and associated OSS node list into a query request, and sends it to the dynamic policy daemon process through a Netlink socket; S5: The dynamic policy daemon receives a query request at its policy decision point. The context sensor collects dynamic attributes in real time. If the system has a policy cache optimization mechanism, the policy engine first queries the cache space. If there is a valid cache item, it directly obtains the decision result. Otherwise, it executes step S6. S6: The strategy engine combines the relevant information in the query request with the collected dynamic attributes. If the system has a hierarchical role inheritance mechanism, it synchronously combines the role hierarchy relationship, queries the dynamic strategy in the strategy rule base for logical evaluation, and generates a decision result. S7: The dynamic policy daemon returns the decision result to the LSM hook function through the Netlink socket. If the system has a policy caching optimization mechanism, the query request and the corresponding decision result and dynamic attribute are stored in the cache space. S8: The LSM hook function performs operations based on the decision result. If the decision result is ALLOW, then the file system operation request is allowed to be sent to the Lustre MDS / OSS backend. If the decision result is DENY, then return -EACCES; S9: If the system has an access behavior auditing mechanism, the LSM hook function generates an audit log and sends it to the audit log storage module for storage after executing the decision.

10. A dynamic role-based access control method based on the Lustre file system according to claim 9, characterized in that, The dynamic policies configured in step S1 include: Users with the role of data_scientist are only allowed to write data to the Lustre directory with the training_zone security label when the global GPU utilization is below a preset threshold. The dynamic attributes collected by the context awareness device in step S5 include global GPU utilization; In step S6, the policy engine determines whether the user role is data_scientist, whether the operation type is write, whether the resource label is training_zone, and whether the global GPU utilization is lower than a preset threshold. If all conditions are met, an ALLOW decision result is generated; otherwise, a DENY decision result is generated.

Images