Authorization verification method, electronic device, storage medium, and program product

Abstract

The present application discloses a method for verifying permissions, an electronic device, a storage medium, and a program product, which relate to the field of computer technology, including obtaining a pre-configured user-defined user group and permission information of each resource type in the user-defined user group, and obtaining a target dynamic scene to be verified, injecting a fault corresponding to the preset scene type according to the preset scene type to which the target dynamic scene belongs, and recovering the fault based on the corresponding fault recovery strategy, and after the fault is recovered, comparing and verifying the current permission information of each resource type in the user-defined user group with the previously configured permission information, and finally obtaining a verification result. The method of the present application, by obtaining pre-configured user groups and permission information, and injecting and recovering faults for different preset scene types, dynamically obtaining permission information after fault recovery, and comparing it with the configured permission information, achieves dynamic multi-scenario coverage and improves the diversity of verification scenarios.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a permission verification method, electronic device, storage medium, and program product. Background Art

[0002] Custom user groups enable business management and control through flexible permission configuration. Verifying the permissions of custom user groups is a core part of data security protection and plays an important role.

[0003] Traditional permission verification methods typically employ static testing with predefined test cases, manually or through scripts to pre-set fixed permission configurations and verify the correctness of the configuration syntax based on pre-set rules. However, this approach is limited in its application scenarios and has limited applicability. Summary of the Invention

[0004] The present application provides a permission verification method, electronic device, storage medium, and program product to at least solve the problem of poor applicability of permission verification methods in related technologies.

[0005] This application provides a permission verification method, including:

[0006] Get pre-configured user-defined user groups and permission information for each resource type in the user-defined user groups;

[0007] Obtain the target dynamic scenario to be verified, which is used to inject faults;

[0008] According to the preset scenario type to which the target dynamic scenario belongs, a fault corresponding to the preset scenario type is injected, and the fault is recovered based on the corresponding fault recovery strategy;

[0009] After failure recovery, obtain the current permission information for each resource type in the user-defined user group;

[0010] Compare and verify the current permission information with the configured permission information to obtain the verification result;

[0011] Among them, the preset scenario types include a first type for indicating that a single storage node fails, a second type for indicating that multiple storage nodes in a cluster fail at the same time, a third type for indicating that the storage service is unavailable, and a fourth type for indicating that the cluster is unavailable.

[0012] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of the above-mentioned method for verifying any one of the permissions when executing the computer program.

[0013] The present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the method for verifying any of the above permissions are implemented.

[0014] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned permission verification methods when the computer program is executed by a processor.

[0015] Through this application, the permission information of the pre-configured user-defined user group and each resource type in the user-defined user group is obtained, and the target dynamic scenario to be verified is obtained. According to the preset scenario type to which the target dynamic scenario belongs, a fault corresponding to the preset scenario type is injected, and based on the corresponding fault recovery strategy, the fault is restored. After the fault is restored, the current permission information of each resource type in the user-defined user group is compared and verified with the previously configured permission information, and finally a verification result is obtained. The method of this application realizes dynamic multi-scenario coverage and improves the diversity of verification scenarios by obtaining pre-configured user groups and permission information, injecting and restoring faults for different preset scenario types, dynamically obtaining permission information after fault recovery, and comparing it with the configured permission information. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 A schematic diagram of the hardware architecture for permission verification provided for this application;

[0018] Figure 2 A flowchart of a method for verifying permissions provided in an embodiment of the present application;

[0019] Figure 3 A flowchart of a method for verifying permissions under the first type provided in an embodiment of the present application;

[0020] Figure 4 A flowchart of a method for verifying permissions under the second type provided in an embodiment of the present application;

[0021] Figure 5 A flowchart of a method for verifying permissions under the third type provided in an embodiment of the present application;

[0022] Figure 6 A flowchart of a method for verifying permissions under the fourth type provided in an embodiment of the present application;

[0023] Figure 7 A schematic diagram of the structure of a permission verification device provided in an embodiment of the present application;

[0024] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0026] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0027] A custom UserDefined user group is a collection of users created and defined by an administrator based on actual business needs or management rules. It enables batch management and flexible control of user permissions by grouping users with the same functions, permissions, or attributes into the same group.

[0028] Custom user group permission management is a flexible access control mechanism that enables batch management of resource access permissions by dividing users with the same permission requirements into different groups. Administrators can independently configure operation permissions for different resource types for each user group based on business needs.

[0029] Verifying the permissions of custom user groups is a key step in ensuring system security and stable operation. By performing permission verification, unauthorized access caused by incorrect permission configuration can be reduced, and users can only access authorized resources, avoiding data leakage or abuse.

[0030] Related technologies often use a static detection model based on predefined test cases when verifying permissions for custom user groups. In this model, technicians manually or through scripting must pre-set fixed permission configurations, such as setting read and write permissions for a specific file for a user group. The verification results are then verified based on pre-defined rules to ensure the correct permission fields are present.

[0031] However, the above method is only suitable for verifying the compliance of permission configuration in a static environment, and cannot simulate dynamic scenarios such as system failures during actual operation. Therefore, its application scenario is relatively single and its applicability is poor.

[0032] In response to the problems in the above-mentioned related technologies, it was found during the research process that the problem of poor applicability of static verification in related technologies can be solved by introducing dynamic scenarios, that is, simulating multiple dynamic scenarios for permission verification by injecting faults. Specifically, first obtain the permission information of the pre-configured user-defined user group and its various resource types, and then obtain the target dynamic scenario to be verified. This scenario is used as a carrier for fault injection to cover different fault levels. The fault level can include single-node failure, multi-node failure, storage service unavailability, cluster unavailability and other fault levels. Then, based on the above-mentioned level to which the target dynamic scenario belongs, targeted fault injection is carried out and recovery is carried out according to the corresponding strategy to simulate actual abnormal situations. After the fault is recovered, the current permission information of each resource type in the custom user group is obtained again to capture the impact of system status changes on permission configuration, and the current permission information obtained is compared with the permission information of the initial configuration to judge the consistency and correctness of the permissions before and after the failure, and finally obtain the verification result. This method breaks through the limitations of traditional static detection by actively simulating failure scenarios, expanding from "normal operation" to "multiple failure states", achieving comprehensive verification of permission configuration in dynamic business processes, and ensuring that permission configuration remains reliable after failure recovery, thereby reducing the risks of data leakage or service interruption caused by permission anomalies.

[0033] In order to better understand the permission verification method of this application, the following is an exemplary architecture diagram, please refer to Figure 1 , Figure 1 A hardware architecture diagram of permission verification provided in this application includes: a controller 01 and a storage system 02, wherein the controller 01 is in communication connection with the storage system 02.

[0034] Controller 01 preconfigures the user-defined user groups required by storage system 02, as well as the permission information for each resource type within the user-defined user group. Controller 01 then injects faults of varying levels corresponding to the dynamic scenarios to be verified by storage system 02 and recovers from the faults. After fault recovery, controller 01 obtains the permission information for each resource type within the user-defined user group and compares it with the preconfigured permission information, ultimately obtaining a verification result indicating whether verification passed or failed.

[0035] It is understandable that the present application does not limit the type, quantity, and connection relationship of the controller 01 and the storage system 02. The above examples are only used for illustration and the specific ones can be determined based on actual application conditions.

[0036] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0037] See Figure 2 , Figure 2 This is a flowchart of a method for verifying permissions provided in an embodiment of the present application. The execution subject of this method may be a permission verification device. The permission verification device may be implemented by a computer program, or by a medium storing a relevant computer program, such as a USB flash drive and / or an optical disk, or by a physical device integrated or installed with a relevant computer program, such as an electronic device, which may be a server, a server cluster, or an intelligent terminal. The method may include the following steps:

[0038] S201: Acquire a pre-configured user-defined user group and permission information of each resource type in the user-defined user group.

[0039] In this embodiment, user-defined user groups and permission information of each resource type in the user-defined user groups are pre-configured.

[0040] Optionally, based on the user group creation instruction, a first user-defined user group testr with read-only permission and a second user-defined user group testall with read-write permission are created.

[0041] The first user-defined user group and the second user-defined user group include multiple resource types, where the resource types include but are not limited to: logical unit (Logical Unit Number, LUN), storage pool (Pool), mapping (map) and copy service (copyservice), etc. Each resource type can also include its own sub-resources. For example, the logical unit can also include LUN migration, the storage pool can also include physical disk groups and physical drives, the mapping can also include virtual disk groups and host groups, and the copy service can also include replication partnership, remote replication, site configuration, etc.

[0042] The permission information of each resource type in the first user-defined user group is configured as read-only permission. For example, the permission information of each resource type in the first user-defined user group is configured as read-only permission.

[0043] The permission information of each resource type in the second user-defined user group is configured as read-write permission. For example, the above resource types of the second user-defined user group are all configured as read-write permission.

[0044] S202: Acquire a target dynamic scene to be verified.

[0045] In this embodiment, the target dynamic scenario is a scenario where faults can be injected, rather than a static scenario that is stable and does not experience faults.

[0046] S203: According to the preset scene type to which the target dynamic scene belongs, inject a fault corresponding to the preset scene type, and recover from the fault based on the corresponding fault recovery strategy.

[0047] Optionally, the preset scenario types may include a first type for indicating that a single storage node fails, a second type for indicating that multiple storage nodes in a cluster fail simultaneously, a third type for indicating that the storage service is unavailable, and a fourth type for indicating that the cluster is unavailable.

[0048] Exemplarily, taking a storage system as an example, if the target dynamic scenario is that a storage node in the storage system is damaged, then the target dynamic scenario belongs to the first type, where the first type can also be called a node-level failure T1 type.

[0049] If the target dynamic scenario is that multiple storage nodes in the storage system are powered off and shut down at the same time, then the target dynamic scenario belongs to the second type, where the second type can also be called cluster-level failure type T2.

[0050] If the target dynamic scenario is a complete collapse of the storage service in the storage system, then the target dynamic scenario belongs to the third type, where the third type may also be referred to as a service reconstruction level failure T3 type.

[0051] If the target dynamic scenario is a complete failure of the entire cluster in the storage system, the target dynamic scenario belongs to the fourth type, where the fourth type may also be referred to as a full cluster reconstruction level failure T4 type.

[0052] It is understandable that the above examples are only for illustration and do not limit the content of this application, which can be determined according to actual application conditions.

[0053] According to the preset scenario type to which the target dynamic scenario belongs, after injecting a fault corresponding to the preset scenario type, the fault is recovered based on the fault recovery strategy corresponding to the preset scenario type to simulate abnormal fault recovery in practice.

[0054] S204: After the failure is recovered, obtain the current permission information of each resource type in the user-defined user group.

[0055] After the fault is recovered, the permission directory information in the first user-defined user group is viewed based on the user group information viewing instruction lsusergrp. The permission directory information includes the current permission information of each resource type in the first user-defined user group.

[0056] Correspondingly, based on the user group information viewing instruction lsusergrp, the permission directory information in the second user-defined user group is viewed, and the permission directory information includes the current permission information of each resource type in the second user-defined user group.

[0057] S205: Compare and verify the current permission information with the configured permission information to obtain a verification result.

[0058] Optionally, the current permission information of each resource type in the first user-defined user group is compared and verified with the permission information of each resource type in the configured first user-defined user group.

[0059] If the comparison is consistent, a first verification result is obtained, which is used to indicate that the permission verification of each resource type in the first user-defined user group is passed, that is, after the fault is recovered, the current permission information of each resource type in the first user-defined user group is also read-only permission.

[0060] If the comparison is inconsistent, a second verification result is obtained, which is used to indicate that the permission verification of each resource type in the first user-defined user group fails, that is, after the fault is recovered, the current permission information of each resource type in the first user-defined user group is not all read-only permission, but also read and write permission.

[0061] Optionally, the current permission information of each resource type in the second user-defined user group is compared and verified with the permission information of each resource type in the configured second user-defined user group.

[0062] If the comparison is consistent, a third verification result is obtained, which is used to indicate that the permission verification of each resource type in the second user-defined user group has passed, that is, after the fault is recovered, the current permission information of each resource type in the second user-defined user group is also read and write permission.

[0063] If the comparison is inconsistent, a fourth verification result is obtained, which is used to indicate that the permission verification of each resource type in the second user-defined user group fails, that is, after the fault is recovered, the current permission information of each resource type in the second user-defined user group is not all read and write permissions, but also read-only permissions.

[0064] In the above-mentioned embodiment of the present application, a pre-configured user-defined user group and the permission information of each resource type in the user-defined user group are obtained, and the target dynamic scenario to be verified is obtained. According to the preset scenario type to which the target dynamic scenario belongs, a fault corresponding to the preset scenario type is injected, and the fault is restored based on the corresponding fault recovery strategy. After the fault is recovered, the current permission information of each resource type in the user-defined user group is obtained, and the current permission information is compared and verified with the configured permission information to finally obtain a verification result. The method of this embodiment, by obtaining pre-configured user groups and permission information, and injecting and recovering faults for different preset scenario types, dynamically obtaining the permission information after the fault is recovered, and comparing it with the configured permission information, achieves dynamic multi-scenario coverage and improves the diversity of verification scenarios.

[0065] Furthermore, based on the above embodiment, the following embodiment illustrates the process of verifying the permissions when the preset scene type to which the target dynamic scene belongs is the first type. Figure 3 , Figure 3 A flowchart of a method for verifying permissions under the first type provided in an embodiment of the present application may include the following steps:

[0066] S301: Based on a user group creation instruction, create a first user-defined user group with read-only permission, and configure permission information of each resource type in the first user-defined user group as read-only permission.

[0067] In this embodiment, the prerequisite is that the storage system is running normally and the user group with the highest level security management role, SecurityAdmin, has logged into the storage system's command line interface (CLI). This allows the user to perform various operations, such as creating user-defined user groups and injecting faults.

[0068] S302: Based on the user group creation instruction, create a second user-defined user group with read and write permissions, and configure permission information of each resource type in the second user-defined user group as read and write permissions.

[0069] The specific creation process has been described in detail in the above embodiment. Please refer to the above embodiment. To avoid redundancy, it will not be repeated.

[0070] S303: Inject a fault, where the fault may be a target storage node downtime fault.

[0071] According to the first type to which the target dynamic scenario belongs, a target storage node preset under the first type is controlled to enter a shutdown state.

[0072] Optionally, based on a command line tool of the storage system, the target storage node is controlled to stop running.

[0073] S304: In response to the user's operation, obtain a restart instruction of the target storage node.

[0074] A restart instruction is acquired according to an input operation of the user, wherein the restart instruction may be an instruction based on a hot restart mode.

[0075] S305: According to the restart instruction, the target storage node is controlled to enter the working state from the shutdown state to recover the shutdown failure of the target storage node.

[0076] Based on the instructions of the hot restart mode, the stopped target storage node is controlled to automatically restart, thereby recovering the shutdown failure of the target storage node.

[0077] S306: After the fault is recovered, obtain and verify the current permission information of each resource type in the user group defined by the first user.

[0078] Based on the user group information viewing instruction lsusergrp, view the permission directory information of the first user-defined user group after the fault is recovered, and obtain the current permission information of each resource type from the permission directory information.

[0079] If the current permission information is consistent with the permission information configured in step S301, that is, both are read-only permissions, the permission information of each resource type in the first user-defined user group is verified to be successful; otherwise, the verification fails.

[0080] S307: After the fault is recovered, obtain and verify the current permission information of each resource type in the second user-defined user group.

[0081] Based on the user group information viewing command lsusergrp, view the permission directory information of the second user-defined user group after the fault is recovered, and obtain the current permission information of each resource type from the permission directory information.

[0082] If the current permission information is consistent with the permission information configured in step S302, that is, both are read and write permissions, the permission information of each resource type in the second user-defined user group is verified successfully; otherwise, the verification fails.

[0083] In the above-described embodiment of the present application, when the preset scenario type to which the target dynamic scenario belongs is the first type, permission information is verified by creating a custom user group with read-only and read-write permissions under the first type, injecting a target storage node downtime failure, and after the failure is recovered, verifying whether the permission information of each resource type of the custom user group is consistent with the initially configured permission information before and after the failure recovery. The method of this embodiment can verify the consistency of the permission information of the custom user group in the dynamic scenario belonging to the first type, thereby improving the accuracy and scenario applicability of the verification method.

[0084] Furthermore, based on the above embodiment, the following embodiment illustrates the process of verifying the permissions when the preset scene type to which the target dynamic scene belongs is the second type. Figure 4 , Figure 4 A flowchart of a method for verifying permissions under the second type provided in an embodiment of the present application may include the following steps:

[0085] S401: Based on a user group creation instruction, create a first user-defined user group with read-only permission, and configure permission information of each resource type in the first user-defined user group as read-only permission.

[0086] In this embodiment, the prerequisite is that the storage system is running normally and the user group with the highest level security management role, SecurityAdmin, has logged into the storage system's command line interface (CLI). This allows the user to perform various operations, such as creating user-defined user groups and injecting faults.

[0087] S402: Based on the user group creation instruction, create a second user-defined user group with read and write permissions, and configure permission information of each resource type in the second user-defined user group as read and write permissions.

[0088] The specific creation process has been described in detail in the above embodiment. Please refer to the above embodiment. To avoid redundancy, it will not be repeated.

[0089] S403: Inject a fault, where the fault may be a simultaneous shutdown of multiple storage nodes in the target cluster.

[0090] According to the second type to which the target dynamic scenario belongs, multiple storage nodes in a target cluster preset under the second type are controlled to enter a shutdown state.

[0091] Optionally, based on a command line tool of the storage system, multiple storage nodes in the target cluster are controlled to stop running.

[0092] S404: In response to the user's operation, obtain a forced restart instruction of the target cluster;

[0093] Get the forced restart instruction based on the user's input operation.

[0094] S405 . According to the forced restart instruction, control multiple storage nodes in the target cluster to enter a working state from a shutdown state, so as to recover from a failure in which multiple storage nodes in the target cluster are shut down at the same time.

[0095] Based on the forced restart command, multiple storage nodes in the target cluster that have stopped running are forced to restart automatically. After the multiple storage nodes recover to the highest available active state and the mirror pairs are in the stable state, the storage system's command line interface is enabled to allow administrators to perform management operations through the command line.

[0096] In this embodiment, the reason for waiting for both mirror pairs to be in a stable state is that when a failure occurs, the mirror pair may be in an asynchronous synchronization state or out of sync. For example, the data of the primary replica has been written, but the mirror replica has not yet completed synchronization, or the failure has caused the mirror pair to be in an abnormal state. If the failure recovery is performed when the mirror pair is not synchronized, it may cause the unsynchronized data to be permanently lost, or the master and slave replicas to have inconsistent data, causing application read errors. Therefore, it is necessary to wait for both mirror pairs to be in a stable state to avoid affecting the subsequent permission verification results.

[0097] Note that in some scenarios, the CLI may be temporarily disabled and need to be re-enabled. If the CLI is not temporarily disabled, re-enabling it is not necessary.

[0098] S406: After the fault is recovered, obtain and verify the current permission information of each resource type in the user group defined by the first user.

[0099] Based on the user group information viewing instruction lsusergrp, view the permission directory information of the first user-defined user group after the fault is recovered, and obtain the current permission information of each resource type from the permission directory information.

[0100] If the current permission information is consistent with the permission information configured in step S401, that is, both are read-only permissions, the permission information of each resource type in the first user-defined user group is verified to be successful; otherwise, the verification fails.

[0101] S407: After the fault is recovered, obtain and verify the current permission information of each resource type in the second user-defined user group.

[0102] Based on the user group information viewing command lsusergrp, view the permission directory information of the second user-defined user group after the fault is recovered, and obtain the current permission information of each resource type from the permission directory information.

[0103] If the current permission information is consistent with the permission information configured in step S402, that is, both are read and write permissions, the permission information of each resource type in the second user-defined user group is verified successfully; otherwise, the verification fails.

[0104] In the above-described embodiment of the present application, when the preset scenario type to which the target dynamic scenario belongs is the second type, permission information is verified by creating a custom user group with read-only and read-write permissions under the second type, injecting a fault that causes multiple storage nodes in the target cluster to enter a shutdown state, and after the fault is recovered, verifying whether the permission information for each resource type of the custom user group before and after the fault recovery is consistent with the initially configured permission information. The method of this embodiment can verify the consistency of the permission information of the custom user group in the dynamic scenario belonging to the second type, thereby improving the accuracy and scenario applicability of the verification method.

[0105] Furthermore, based on the above embodiment, the following embodiment illustrates the process of verifying the permissions when the preset scene type to which the target dynamic scene belongs is the third type. Figure 5 , Figure 5 A flowchart of a method for verifying permissions under the third type provided in an embodiment of the present application may include the following steps:

[0106] S501: Based on a user group creation instruction, create a first user-defined user group with read-only permission, and configure permission information of each resource type in the first user-defined user group as read-only permission.

[0107] In this embodiment, the prerequisite is that the storage system is running normally and the user group with the highest level security management role, SecurityAdmin, has logged into the storage system's command line interface (CLI). This allows the user to perform various operations, such as creating user-defined user groups and injecting faults.

[0108] S502: Based on the user group creation instruction, create a second user-defined user group with read and write permissions, and configure permission information of each resource type in the second user-defined user group as read and write permissions.

[0109] The specific creation process has been described in detail in the above embodiment. Please refer to the above embodiment. To avoid redundancy, it will not be repeated.

[0110] S503: Inject a fault, which may be a storage service unavailability fault.

[0111] According to the third type to which the target dynamic scenario belongs, the storage service preset under the third type is controlled to enter an unavailable state, wherein the unavailable state is used to indicate that the target cluster executing the storage service and the storage nodes in the target cluster enter an inoperative state.

[0112] S504: Back up the configuration information of the storage node based on the preset backup instruction.

[0113] According to the pre-set backup instructions, the configuration information of the storage node is backed up to the preset storage location to prevent the loss of configuration information and provide a data basis for subsequent fault recovery.

[0114] S505: Based on a preset node restart instruction, control the storage node to enter a startup state from an idle state.

[0115] Forcefully restart the storage node according to the pre-set node restart instructions to start the storage service. Wait for the storage node to return to the Service 690 state, which indicates that the storage service has started. This forced restart restores the node's basic functionality and prepares it for subsequent use.

[0116] S506 : Based on the preset node exit instruction, control the storage node to exit the target cluster.

[0117] According to the pre-set node exit instruction, the storage node is controlled to forcibly exit the target cluster and disconnect from other storage nodes. By clearing the connection status with other storage nodes, it is used to prepare for subsequent cluster recovery.

[0118] S507 : Based on the preset node execution instruction, control the storage node to enter the candidate state.

[0119] Executes instructions according to pre-set nodes, stops storage services, releases storage node resources, and waits for the storage node to enter the Candidate state. The Candidate state is used to indicate that the storage service has been stopped and is waiting to rejoin the cluster to prepare for reinitialization for subsequent fault recovery.

[0120] S508. Based on the preset cluster recovery instructions and according to the configuration information of the backed-up storage nodes, the candidate storage nodes are reconfigured, and the reconfigured storage nodes are controlled to rejoin the target cluster so that the target cluster enters a normal operating state to recover from the failure of the storage service being unavailable.

[0121] According to the pre-set prepare instructions in the cluster recovery instructions, the previously backed-up storage node configuration information is loaded and the candidate storage nodes are reconfigured to restore the cluster configuration and ensure data consistency. According to the pre-set run instructions in the cluster recovery instructions, the reconfigured storage nodes are controlled to rejoin the target cluster. Once the storage nodes are restored to the active state, the target cluster resumes normal operation.

[0122] S509: After the fault is recovered, obtain and verify the current permission information of each resource type in the first user-defined user group.

[0123] S510: After the fault is recovered, the current permission information of each resource type in the second user-defined user group is obtained and verified.

[0124] The process of verifying the current permission information for each resource type in the first user-defined user group in step S509 is the same as in the above embodiment and will not be repeated here to avoid redundancy. Accordingly, the process of verifying the current permission information for each resource type in the second user-defined user group in step S510 will not be repeated here either; please refer to the above embodiment.

[0125] In the above-mentioned embodiment of the present application, when the preset scenario type to which the target dynamic scenario belongs is the third type, the permission information is verified by creating a custom user group with read-only and read-write permissions under the third type, injecting a fault that causes the preset storage service under the third type to enter an unavailable state, and after the fault is recovered, verifying whether the permission information of each resource type of the custom user group before and after the fault recovery is consistent with the initially configured permission information. The method of this embodiment can verify the consistency of the permission information of the custom user group in the dynamic scenario belonging to the third type, thereby improving the accuracy and scenario applicability of the verification method.

[0126] Furthermore, based on the above embodiment, the following embodiment illustrates the process of verifying the permissions when the preset scene type to which the target dynamic scene belongs is the fourth type. Figure 6 , Figure 6 A flowchart of a method for verifying permissions under the fourth type provided in an embodiment of the present application may include the following steps:

[0127] S601: Based on a user group creation instruction, create a first user-defined user group with read-only permission, and configure permission information of each resource type in the first user-defined user group as read-only permission.

[0128] In this embodiment, the prerequisite is that the storage system is running normally and the user group with the highest level security management role, SecurityAdmin, has logged into the storage system's command line interface (CLI). This allows the user to perform various operations, such as creating user-defined user groups and injecting faults.

[0129] S602: Based on the user group creation instruction, create a second user-defined user group with read and write permissions, and configure permission information of each resource type in the second user-defined user group as read and write permissions.

[0130] The specific creation process has been described in detail in the above embodiment. Please refer to the above embodiment. To avoid redundancy, it will not be repeated.

[0131] S603: Inject a fault, where the fault may be a target cluster unavailable fault.

[0132] According to the fourth type to which the target dynamic scene belongs, a target cluster preset under the fourth type is controlled to enter an unavailable state.

[0133] S604: Back up the configuration information of the storage nodes included in the target cluster based on the preset backup instruction.

[0134] According to the pre-set backup instructions, the configuration information of the storage node is backed up to the preset storage location to save the current cluster configuration, prevent the loss of configuration information, and provide a data basis for subsequent fault recovery.

[0135] S605: Based on a preset node restart instruction, control the storage node to enter a startup state from an idle state.

[0136] According to the pre-set node restart instructions, the storage node is forcibly started to forcibly start the storage service, and the storage node is restored to the Active state and the mirror pair reaches the Stable state.

[0137] S606: Based on the preset node exit instruction, control the storage node to exit the target cluster.

[0138] According to the pre-set node exit instruction, the storage node is controlled to forcibly exit the target cluster and disconnect from other storage nodes. By clearing the connection status with other storage nodes, it is used to prepare for the subsequent reconstruction of the cluster.

[0139] S607: Based on the preset node execution instruction, control the storage node to enter the candidate state.

[0140] According to the pre-set node execution instructions, the storage service is stopped, the storage node resources are released, and the storage node is waited for to enter the Candidate state. The Candidate state is used to indicate that the storage service has been stopped and is waiting to rejoin the newly created cluster to prepare for reinitialization for subsequent fault recovery.

[0141] S608: Create a new cluster based on the preset cluster reconstruction instruction.

[0142] According to the pre-set cluster reconstruction instructions, control the reinitialization of the cluster to avoid conflicts between the new cluster and the old cluster.

[0143] S609. Based on the preset cluster restoration instructions, the candidate storage nodes are reconfigured according to the configuration information of the backed-up storage nodes, and the reconfigured storage nodes are controlled to join the new cluster so that the new cluster enters a normal operating state to recover from the cluster unavailability failure.

[0144] According to the pre-set prepare instructions in the cluster restore instructions, the previously backed-up storage node configuration information of the target cluster is loaded, and the candidate storage nodes are reconfigured to ensure data consistency. According to the pre-set run instructions in the cluster restore instructions, the reconfigured storage nodes are controlled to rejoin the new cluster. After the storage nodes return to the active state, the target cluster resumes normal operation.

[0145] S610: After the fault is recovered, obtain and verify the current permission information of each resource type in the first user-defined user group.

[0146] S611: After the fault is recovered, the current permission information of each resource type in the second user-defined user group is obtained and verified.

[0147] The specific implementation process of step S610 and step S611 can be found in the above embodiment, and will not be described again to avoid redundancy.

[0148] In the above-mentioned embodiment of the present application, when the preset scenario type to which the target dynamic scenario belongs is the fourth type, the permission information is verified by creating a custom user group with read-only and read-write permissions under the fourth type, injecting a fault that causes the preset target cluster under the fourth type to enter an unavailable state, and after the fault is recovered, verifying whether the permission information of each resource type of the custom user group before and after the fault recovery is consistent with the initially configured permission information. The method of this embodiment can verify the consistency of the permission information of the custom user group in the dynamic scenario belonging to the fourth type, thereby improving the accuracy and scenario applicability of the verification method.

[0149] In this application, through Figure 5 and Figure 6 The illustrated embodiment demonstrates that customized permission configuration can fully support system-level backup and recovery and cross-cluster reconstruction operations to ensure business continuity.

[0150] In this application, the above-mentioned multiple preset scenario types can also be nested and used. By injecting at least two types of corresponding faults at the same time, the permission information of each resource type in the custom user group after fault recovery under different types can be verified together, so as to verify the robustness under superimposed faults.

[0151] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0152] See Figure 7 , Figure 7This is a schematic diagram of the structure of a permission verification device provided in an embodiment of the present application, wherein the permission verification device includes:

[0153] The acquisition module 701 is used to acquire the pre-configured user-defined user group and the permission information of each resource type in the user-defined user group.

[0154] The acquisition module 701 is further configured to acquire a target dynamic scenario to be verified, where the target dynamic scenario is used to inject faults.

[0155] The processing module 702 is configured to inject a fault corresponding to the preset scene type according to the preset scene type to which the target dynamic scene belongs, and recover from the fault based on the corresponding fault recovery strategy.

[0156] The acquisition module 701 is further configured to acquire the current permission information of each resource type in the user-defined user group after the fault is recovered.

[0157] The verification module 703 is used to compare and verify the current permission information with the configured permission information to obtain a verification result.

[0158] Among them, the preset scenario types include a first type for indicating that a single storage node fails, a second type for indicating that multiple storage nodes in a cluster fail at the same time, a third type for indicating that the storage service is unavailable, and a fourth type for indicating that the cluster is unavailable.

[0159] In one possible implementation, before obtaining the pre-configured user-defined user group and the permission information of each resource type in the user-defined user group, the processing module 702 is further configured to:

[0160] Based on the user group creation instruction, a first user-defined user group with read-only permission and a second user-defined user group with read-write permission are created, and the first user-defined user group and the second user-defined user group include multiple resource types.

[0161] The permission information of each resource type in the first user-defined user group is configured as read-only permission.

[0162] Configure the permission information of each resource type in the second user-defined user group to be read and write permissions.

[0163] In one possible implementation, when the preset scenario type to which the target dynamic scenario belongs is the first type and the fault is a target storage node shutdown fault, a fault corresponding to the preset scenario type is injected according to the preset scenario type to which the target dynamic scenario belongs, and the fault is recovered based on a fault recovery strategy corresponding to the preset scenario type. The processing module 702 is specifically configured to:

[0164] According to the first type to which the target dynamic scenario belongs, a target storage node preset under the first type is controlled to enter a shutdown state.

[0165] In response to the user's operation, a restart instruction of the target storage node is obtained.

[0166] According to the restart instruction, the target storage node is controlled to enter the working state from the shutdown state to recover the shutdown failure of the target storage node.

[0167] One possible implementation is that, when the preset scenario type to which the target dynamic scenario belongs is the second type and the fault is a simultaneous shutdown fault of multiple storage nodes in the target cluster, a fault corresponding to the preset scenario type is injected according to the preset scenario type to which the target dynamic scenario belongs, and the fault is recovered based on the fault recovery strategy corresponding to the preset scenario type. The processing module 702 is specifically configured to:

[0168] According to the second type to which the target dynamic scenario belongs, multiple storage nodes in a target cluster preset under the second type are controlled to enter a shutdown state.

[0169] In response to the user's operation, a forced restart instruction of the target cluster is obtained.

[0170] According to the forced restart instruction, multiple storage nodes in the target cluster are controlled to enter the working state from the shutdown state to recover from the failure of multiple storage nodes in the target cluster being shut down at the same time.

[0171] One possible implementation is that, when the preset scenario type to which the target dynamic scenario belongs is the third type and the fault is unavailability of the storage service, a fault corresponding to the preset scenario type is injected according to the preset scenario type to which the target dynamic scenario belongs, and the fault is recovered based on the fault recovery strategy corresponding to the preset scenario type. The processing module 702 is specifically configured to:

[0172] According to the third type to which the target dynamic scenario belongs, the storage service preset under the third type is controlled to enter an unavailable state, and the unavailable state is used to indicate that the target cluster executing the storage service and the storage nodes in the target cluster enter an inoperative state.

[0173] Back up the configuration information of the storage node based on the preset backup instructions.

[0174] Based on the preset node restart instruction, control the storage node from the idle state to the startup state.

[0175] Based on the preset node exit instructions, control the storage node to exit the target cluster.

[0176] Based on the preset node execution instructions, the storage node is controlled to enter the candidate state.

[0177] Based on the preset cluster recovery instructions, the candidate storage nodes are reconfigured according to the configuration information of the backed-up storage nodes, and the reconfigured storage nodes are controlled to rejoin the target cluster so that the target cluster enters a normal operating state to recover from the failure of the storage service being unavailable.

[0178] One possible implementation is that, when the preset scenario type to which the target dynamic scenario belongs is the fourth type and the fault is that the target cluster is unavailable, a fault corresponding to the preset scenario type is injected according to the preset scenario type to which the target dynamic scenario belongs, and the fault is recovered based on the fault recovery strategy corresponding to the preset scenario type. The processing module 702 is specifically configured to:

[0179] According to the fourth type to which the target dynamic scene belongs, a target cluster preset under the fourth type is controlled to enter an unavailable state.

[0180] Back up the configuration information of the storage nodes included in the target cluster based on the preset backup instructions.

[0181] Based on the preset node restart instruction, control the storage node from the idle state to the startup state.

[0182] Based on the preset node exit instructions, control the storage node to exit the target cluster.

[0183] Based on the preset node execution instructions, the storage node is controlled to enter the candidate state.

[0184] Create a new cluster based on the preset cluster reconstruction instructions.

[0185] Based on the preset cluster restoration instructions, the candidate storage nodes are reconfigured according to the configuration information of the backed-up storage nodes, and the reconfigured storage nodes are controlled to join the new cluster so that the new cluster enters a normal operating state to recover from the cluster unavailability failure.

[0186] One possible implementation is to compare and verify the current permission information with the configured permission information to obtain a verification result. The verification module 703 is specifically used to:

[0187] The current permission information of each resource type in the first user-defined user group is compared and verified with the permission information of each resource type in the configured first user-defined user group.

[0188] If the comparison is consistent, a first verification result is obtained, and the first verification result is used to indicate that the permission verification of each resource type in the user group defined by the first user is passed.

[0189] If the comparison is inconsistent, a second verification result is obtained, and the second verification result is used to indicate that the permission verification of each resource type in the user group defined by the first user fails.

[0190] One possible implementation is to compare and verify the current permission information with the configured permission information to obtain a verification result. The verification module 703 is specifically used to:

[0191] The current permission information of each resource type in the second user-defined user group is compared and verified with the permission information of each resource type in the configured second user-defined user group.

[0192] If the comparison is consistent, a third verification result is obtained, and the third verification result is used to indicate that the permission verification of each resource type in the second user-defined user group is passed.

[0193] If the comparison is inconsistent, a fourth verification result is obtained, and the fourth verification result is used to indicate that the permission verification of each resource type in the second user-defined user group has failed.

[0194] For the description of the features in the embodiment corresponding to the authority verification device of this embodiment, reference can be made to the relevant description of the embodiment corresponding to the authority verification method, which will not be repeated here.

[0195] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 8 As shown, the electronic device provided in this embodiment includes: at least one processor 801 and a memory 802. Optionally, the electronic device further includes a communication component 803. The processor 801, the memory 802 and the communication component 803 are connected via a bus 804.

[0196] In a specific implementation process, at least one processor 801 executes the computer-executable instructions stored in the memory 802, so that the at least one processor 801 executes the above-mentioned permission verification method embodiment.

[0197] The specific implementation process of the processor 801 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0198] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the application may be directly executed by a hardware processor or by a combination of hardware and software modules within the processor.

[0199] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0200] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0201] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned permission verification method embodiments when running.

[0202] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0203] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned permission verification method embodiments are implemented.

[0204] An embodiment of the present application further provides another computer program product, comprising a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned permission verification method embodiments are implemented.

[0205] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0206] The above is a detailed introduction to the permission verification method, electronic device, storage medium and program product provided by this application. Specific examples are used herein to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core idea of ​​this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A method for verifying authority, characterized in that: include: Obtaining pre-configured user-defined user groups and permission information for each resource type in the user-defined user groups; Acquire a target dynamic scenario to be verified, where the target dynamic scenario is used to inject a fault; According to the preset scene type to which the target dynamic scene belongs, injecting a fault corresponding to the preset scene type, and recovering the fault based on the corresponding fault recovery strategy; After the fault is recovered, obtaining current permission information of each resource type in the user-defined user group; Comparing and verifying the current permission information with the configured permission information to obtain a verification result; Among them, the preset scenario types include a first type for indicating that a single storage node fails, a second type for indicating that multiple storage nodes in a cluster fail at the same time, a third type for indicating that the storage service is unavailable, and a fourth type for indicating that the cluster is unavailable.

2. The method according to claim 1, characterized in that Before obtaining the pre-configured user-defined user group and the permission information of each resource type in the user-defined user group, the method further includes: Based on the user group creation instruction, create a first user-defined user group with read-only permission and a second user-defined user group with read-write permission, wherein the first user-defined user group and the second user-defined user group include multiple resource types; Configuring the permission information of each resource type in the first user-defined user group as read-only permission; The permission information of each resource type in the second user-defined user group is configured as read and write permissions.

3. The method according to claim 2, characterized in that When the preset scenario type to which the target dynamic scenario belongs is the first type and the fault is a target storage node shutdown fault, injecting a fault corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, and recovering the fault based on a fault recovery strategy corresponding to the preset scenario type, includes: According to the first type to which the target dynamic scenario belongs, controlling the target storage node preset under the first type to enter a shutdown state; In response to a user operation, obtaining a restart instruction of the target storage node; According to the restart instruction, the target storage node is controlled to enter the working state from the shutdown state to recover the shutdown failure of the target storage node.

4. The method according to claim 2, characterized in that When the preset scenario type to which the target dynamic scenario belongs is the second type, and the fault is a simultaneous shutdown fault of multiple storage nodes in the target cluster, injecting a fault corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, and recovering the fault based on a fault recovery strategy corresponding to the preset scenario type, includes: According to the second type to which the target dynamic scenario belongs, controlling multiple storage nodes in a target cluster preset under the second type to enter a shutdown state; In response to a user operation, obtaining a forced restart instruction of the target cluster; According to the forced restart instruction, multiple storage nodes in the target cluster are controlled to enter the working state from the shutdown state, so as to recover from the failure of multiple storage nodes in the target cluster being shut down at the same time.

5. The method according to claim 2, characterized in that When the preset scenario type to which the target dynamic scenario belongs is the third type and the fault is unavailability of the storage service, injecting a fault corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, and recovering the fault based on a fault recovery strategy corresponding to the preset scenario type, includes: According to the third type to which the target dynamic scenario belongs, controlling a storage service preset under the third type to enter an unavailable state, wherein the unavailable state is used to indicate that a target cluster executing the storage service and a storage node in the target cluster enter an inoperative state; Backing up the configuration information of the storage node based on a preset backup instruction; Based on a preset node restart instruction, controlling the storage node to enter a startup state from the non-working state; Based on a preset node exit instruction, control the storage node to exit the target cluster; Based on a preset node execution instruction, control the storage node to enter a candidate state; Based on the preset cluster recovery instructions, the storage nodes in the candidate state are reconfigured according to the configuration information of the backed-up storage nodes, and the reconfigured storage nodes are controlled to rejoin the target cluster so that the target cluster enters a normal operating state to recover the failure of the storage service being unavailable.

6. The method according to claim 2, characterized in that When the preset scenario type to which the target dynamic scenario belongs is the fourth type and the fault is unavailability of the target cluster, injecting a fault corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, and recovering the fault based on a fault recovery strategy corresponding to the preset scenario type, includes: According to the fourth type to which the target dynamic scene belongs, controlling the target cluster preset under the fourth type to enter an unavailable state; Backing up the configuration information of the storage nodes included in the target cluster based on a preset backup instruction; Based on a preset node restart instruction, control the storage node from an inactive state to a startup state; Based on a preset node exit instruction, control the storage node to exit the target cluster; Based on a preset node execution instruction, control the storage node to enter a candidate state; Create a new cluster based on the preset cluster reconstruction instructions; Based on the preset cluster restoration instruction, the storage nodes in the candidate state are reconfigured according to the configuration information of the backed-up storage nodes, and the reconfigured storage nodes are controlled to join the new cluster so that the new cluster enters a normal operating state to recover from the failure of cluster unavailability.

7. The method according to any one of claims 2 to 6, characterized in that: Comparing and verifying the current permission information with the configured permission information to obtain a verification result includes: Comparing and verifying the current permission information of each resource type in the first user-defined user group with the configured permission information of each resource type in the first user-defined user group; If the comparison is consistent, a first verification result is obtained, where the first verification result is used to indicate that the permission verification of each resource type in the user group defined by the first user has passed; If the comparison is inconsistent, a second verification result is obtained, where the second verification result is used to indicate that the permission verification for each resource type in the user group defined by the first user fails.

8. The method according to any one of claims 2 to 6, characterized in that: Comparing and verifying the current permission information with the configured permission information to obtain a verification result includes: Compare and verify the current permission information of each resource type in the second user-defined user group with the configured permission information of each resource type in the second user-defined user group; If the comparison is consistent, a third verification result is obtained, and the third verification result is used to indicate that the permission verification of each resource type in the second user-defined user group is passed; If the comparison is inconsistent, a fourth verification result is obtained, and the fourth verification result is used to indicate that the permission verification of each resource type in the second user-defined user group has failed.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the method for verifying permissions as claimed in any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for verifying authority according to any one of claims 1 to 8.

11. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method for verifying authority according to any one of claims 1 to 8 are implemented.

Images