Authority verification method, electronic equipment, storage medium and program product

Abstract

The invention discloses a permission verification method, electronic equipment, a storage medium and a program product, and relates to the technical field of computers, and the method comprises the steps: obtaining a pre-configured user-defined user group and permission information of each resource type in the user-defined user group, and obtaining a to-be-verified target dynamic scene, and according to a preset scene type to which the target dynamic scene belongs, injecting a fault corresponding to the preset scene type, recovering the fault based on a corresponding fault recovery strategy, after the fault is recovered, performing comparison verification on the current permission information of each resource type in the user-defined user group and the previously configured permission information, and finally obtaining a verification result. According to the method provided by the invention, the pre-configured user group and authority information are acquired, the fault is injected and recovered for different preset scene types, the authority information after fault recovery is dynamically acquired, and the authority information is compared with the configured authority information, so that dynamic multi-scene coverage is realized, and the diversity of verification scenes is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a method for verifying permissions, an electronic device, a storage medium, and a program product. Background Art

[0002] Custom user groups control business operations by flexibly configuring permissions. Verifying the permissions of custom user groups is a core part of data security protection and plays an important role.

[0003] In related technologies, traditional permission verification methods usually adopt a static detection mode of predefined test cases, where fixed permission configurations are set in advance manually or through scripts, and the correctness of the configuration syntax is verified based on preset rules. However, this method has a single applicable scenario and poor applicability. Summary of the Invention

[0004] This application provides a method for verifying permissions, an electronic device, a storage medium, and a program product to at least solve the problem of poor applicability of the permission verification method in related technologies.

[0005] This application provides a method for verifying permissions, including:

[0006] Obtain the pre-configured user-defined user group and the permission information of each resource type in the user-defined user group;

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

[0008] According to the preset scenario type to which the target dynamic scenario belongs, inject the fault corresponding to the preset scenario type, and recover the fault based on the corresponding fault recovery strategy;

[0009] After the fault is recovered, obtain the current permission information of each resource type in the user-defined user group;

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

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

[0012] This application also provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above permission verification methods when executing the computer program.

[0013] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any one of the above-mentioned authentication methods are implemented.

[0014] The present application also provides a computer program product, including a computer program. When the computer program is executed by a processor, the steps of any one of the above-mentioned authentication methods are implemented.

[0015] Through the present application, pre-configured user-defined user groups and permission information of each resource type in the user-defined user groups are obtained, and a target dynamic scenario to be verified is obtained. According to the preset scenario type to which the target dynamic scenario belongs, a corresponding fault is injected, and based on the corresponding fault recovery policy, the fault is recovered. After the fault is recovered, 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 the present application realizes dynamic multi-scenario coverage and improves the diversity of verification scenarios by obtaining pre-configured user groups and permission information, injecting and recovering faults for different preset scenario types, dynamically obtaining the 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 drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0017] Figure 1 It is a schematic diagram of the hardware architecture for permission verification provided by the present application;

[0018] Figure 2 It is a schematic flowchart of a method for verifying permissions provided by an embodiment of the present application;

[0019] Figure 3 It is a schematic flowchart of a method for verifying permissions of a first type provided by an embodiment of the present application;

[0020] Figure 4 It is a schematic flowchart of a method for verifying permissions of a second type provided by an embodiment of the present application;

[0021] Figure 5 It is a schematic flowchart of a method for verifying permissions of a third type provided by an embodiment of the present application;

[0022] Figure 6 It is a schematic flowchart of a method for verifying permissions of a fourth type provided by an embodiment of the present application;

[0023] Figure 7 A structural schematic diagram of an authentication device for permissions provided by an embodiment of the present application;

[0024] Figure 8 A structural schematic diagram of an electronic device provided by an embodiment of the present application. Specific embodiments

[0025] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

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

[0027] The custom UserDefined user group refers to a set of users independently created and defined by the administrator according to actual business requirements or management rules. It classifies users with the same functions, permission requirements or attributes into the same group to achieve batch management and flexible control of user permissions.

[0028] The custom user group permission management is a flexible access control mechanism. By dividing users with the same permission requirements into different groups, it realizes batch management of resource access permissions. The administrator can independently configure the operation permissions of different resource types for each user group according to business requirements.

[0029] Verifying the custom user group permissions is a key link to ensure the secure and stable operation of the system. By performing permission verification, it is possible to reduce unauthorized access caused by incorrect permission configurations, so that users can only access authorized resources and avoid data leakage or abuse.

[0030] In the related art, when verifying the custom user group permissions, a static detection mode based on predefined test cases is used. In this mode, technicians need to manually or write scripts to set fixed permission configurations in advance, such as setting read and write permissions for a specific file for a certain user group, and then verifying whether the correct permission fields are included according to the pre-set rules to obtain the verification result.

[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 view of the problems in the above-mentioned related technologies, it was found in the process of research 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, inject faults in a targeted manner and recover 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 state changes on permission configuration, and the current permission information obtained is compared with the permission information of the initial configuration to determine 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 fault scenarios, expanding from "normal operation state" to "multiple fault states", and achieving comprehensive verification of permission configuration in dynamic business processes, ensuring that permission configuration remains reliable after fault 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 exemplary architecture diagram is provided. Figure 1 , Figure 1 A schematic diagram of a hardware architecture for permission verification provided for 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] The controller 01 pre-configures the user-defined user group required by the storage system 02, as well as the permission information of each resource type in the user-defined user group. Then, according to the dynamic scenario to be verified by the storage system 02, the controller 01 injects corresponding faults of different levels into different dynamic scenarios, and recovers the faults. The controller 01 obtains the permission information of each resource type in the user-defined user group after the fault is recovered, and compares and verifies it with the previously pre-configured permission information, and finally obtains the verification result, which is used to indicate whether the verification is passed or not.

[0035] It can be understood that in the present application, the types, quantities, connection relationships, etc. of the controller 01 and the storage system 02 are not limited. The above examples are only for illustrative purposes and can be determined specifically according to actual application scenarios, etc.

[0036] To enable those skilled in the art of this technical field to better understand the solution of the present application, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0037] Please refer to Figure 2 , Figure 2 which is a schematic flowchart of a method for verifying permissions provided by an embodiment of the present application. The execution subject of this method can be a permission verification device. The permission verification device can be implemented through a computer program, or through a medium storing relevant computer programs, such as a USB flash drive and / or an optical disc, etc., or can also be implemented through an entity device integrated or installed with relevant computer programs, such as an electronic device, etc. The electronic device can be a server, a server cluster, a smart terminal, etc. This method can include the following steps:

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

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

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

[0041] The first user-defined user group and the second user-defined user group include multiple resource types. Among them, the resource types include but are not limited to: Logical Unit Number (LUN), Pool, map, and copy service, etc. Under each resource type, there can also be subordinate sub-resources. For example, in the logical unit, there can also be LUN migration, in the storage pool, there can also be physical disk groups and physical drives, in the map, there can also be virtual disk groups and host groups, and the copy service can also include copy partnerships, remote replication, site configuration, etc.

[0042] Configure the permission information of each resource type in the first user-defined user group as read-only permissions. For example, configure the above resource types of the first user-defined user group as read-only permissions.

[0043] Configure the permission information of each resource type in the second user-defined user group to read-write permission. For example, configure the above-mentioned resource types in the second user-defined user group to read-write permission.

[0044] S202. Obtain the target dynamic scenario to be verified.

[0045] In this embodiment, the target dynamic scenario is a scenario where a fault can be injected, rather than a static scenario where no fault occurs stably.

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

[0047] Optionally, the preset scenario type may include a first type for indicating that a single storage node fails, a second type for indicating that multiple storage nodes in the 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 the storage system as an example, if the target dynamic scenario is that a certain 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 the node-level fault T1 type.

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

[0050] If the target dynamic scenario is that the storage service in the storage system completely crashes, then the target dynamic scenario belongs to the third type, where the third type can also be called the service reconstruction-level fault T3 type.

[0051] If the target dynamic scenario is that the entire cluster in the storage system completely fails, then the target dynamic scenario belongs to the fourth type, where the fourth type can also be called the full-cluster reconstruction-level fault T4 type.

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

[0053] After injecting a fault corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, recover the fault based on the fault recovery policy corresponding to the preset scenario type to simulate the fault exception recovery in reality.

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

[0055] After a fault recovery, based on the user group information viewing instruction "lsusergrp", view the permission directory information in the first user-defined user group. The permission directory information will include 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", view the permission directory information in the second user-defined user group. The permission directory information will include 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, compare and verify the current permission information of each resource type in the first user-defined user group with the permission information of each resource type in the configured first user-defined user group.

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

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

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

[0062] If the comparison is consistent, obtain a third verification result. The third verification result is used to indicate that the permission verification of each resource type in the second user-defined user group passes, that is, the current permission information of each resource type in the second user-defined user group after the fault recovery is also read-write permission.

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

[0064] In the above embodiments of the present application, the pre-configured user-defined user groups and the permission information of each resource type in the user-defined user groups 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 recovered based on the corresponding fault recovery policy. After the fault recovery, 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 the verification result. The method of this embodiment realizes dynamic multi-scenario coverage and improves the diversity of verification scenarios by obtaining the pre-configured user groups and permission information, injecting and recovering faults for different preset scenario types, and dynamically obtaining the permission information after fault recovery and comparing it with the configured permission information.

[0065] Further, on the basis of the above embodiments, the following embodiments illustrate the permission verification process when the preset scenario type to which the target dynamic scenario belongs is the first type. Please refer to Figure 3 , Figure 3 FIG. is a schematic flow chart of a permission verification method provided by an embodiment of the present application under the first type, which may include the following steps:

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

[0067] In this embodiment, the precondition is that the storage system is running normally, and the user group with the highest-level security management role SecurityAdmin has logged in to the command line interface (CLI) of the storage system, so that various operations such as creating user-defined user groups and injecting faults can be performed.

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

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

[0070] S303. Inject a fault, and the fault can be a target storage node downtime fault.

[0071] According to the first type to which the target dynamic scenario belongs, control the preset target storage node under the first type to enter the downtime state.

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

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

[0074] Obtain the restart instruction according to the input operation of the user, where the restart instruction may be an instruction based on the hot restart mode.

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

[0076] Based on the instruction of the hot restart mode, control the stopped target storage node to automatically restart, so as to recover the shutdown failure of the target storage node.

[0077] S306. After the failure recovery, obtain and verify the current permission information of each resource type in the first user-defined user group.

[0078] Based on the user group information viewing instruction lsusergrp, view the permission directory information in the first user-defined user group after the failure recovery, 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 verification of the permission information of each resource type in the first user-defined user group passes; otherwise, the verification fails.

[0080] S307. After the failure recovery, 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 instruction lsusergrp, view the permission directory information in the second user-defined user group after the failure recovery, 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-write permissions, the verification of the permission information of each resource type in the second user-defined user group passes; otherwise, the verification fails.

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

[0084] Further, based on the above embodiments, the following embodiments illustrate the permission verification process when the preset scenario type to which the target dynamic scenario belongs is the second type. Please refer to Figure 4 , Figure 4 which is a schematic flowchart of a permission verification method for the second type provided by an embodiment of the present application, and may include the following steps:

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

[0086] In this embodiment, the precondition is that the storage system is running normally, and the user group with the highest-level security management role SecurityAdmin has logged in to the command line interface (CLI) of the storage system, so that various operations such as creating user-defined user groups and injecting faults can be performed.

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

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

[0089] S403. Inject a fault, which can be that multiple storage nodes in the target cluster simultaneously experience downtime faults.

[0090] According to the second type to which the target dynamic scenario belongs, control multiple storage nodes in the preset target cluster in the second type to enter the downtime state.

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

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

[0093] Obtain the forced restart instruction according to the user's input operation.

[0094] S405. According to the forced restart instruction, control multiple storage nodes in the target cluster to enter the working state from the downtime state to recover the fault that multiple storage nodes in the target cluster simultaneously experience downtime.

[0095] Based on the forced restart instruction, control multiple storage nodes that have stopped running in the target cluster to forcefully restart automatically. After multiple storage nodes resume to the highest available active state and all mirror pairs are in the stable state, enable the command-line interface of the storage system to allow the administrator to perform management operations through the command line.

[0096] In this embodiment, the reason for waiting for all mirror pairs to be in the stable state is that when a failure occurs, the mirror pairs may be in the asynchronous synchronization or unsynchronized state. For example, the primary replica data has been written, but the mirror replica has not completed synchronization, or the failure causes the mirror pair status to be abnormal. If a failure recovery is performed when the mirror pair has not completed synchronization, it may cause the unsynchronized data to be permanently lost, or the master-slave replica data to be inconsistent, resulting in application read errors. Therefore, it is necessary to wait for all mirror pairs to be in the stable state to avoid affecting the subsequent permission verification results.

[0097] It should be noted that in some scenarios, the CLI may be temporarily disabled, so it needs to be re-enabled. If the CLI has not been temporarily disabled, there is no need to re-enable it.

[0098] S406. After the failure recovery, obtain and verify the current permission information of each resource type in the first user-defined user group.

[0099] Based on the user group information viewing instruction lsusergrp, view the permission directory information in the first user-defined user group after the failure recovery, 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 verification of each resource type in the first user-defined user group passes; otherwise, the verification fails.

[0101] S407. After the failure recovery, 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 instruction lsusergrp, view the permission directory information in the second user-defined user group after the failure recovery, 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-write permissions, the permission information verification of each resource type in the second user-defined user group passes; otherwise, the verification fails.

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

[0105] Further, on the basis of the above embodiments, the following embodiments illustrate the permission verification process when the preset scenario type to which the target dynamic scenario belongs is the third type. Please refer to Figure 5 , Figure 5 which is a schematic flowchart of a permission verification method provided in an embodiment of the present application under the third type, and may include the following steps:

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

[0107] In this embodiment, the prerequisite is that the storage system is running normally, and a user group with the highest-level security management role SecurityAdmin has logged in to the command line interface (CLI) of the storage system, so that various operations such as creating a user-defined user group and injecting faults can be performed.

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

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

[0110] S503. Inject a fault, and the fault can be a storage service unavailable fault.

[0111] According to the third type to which the target dynamic scenario belongs, control the preset storage service under the third type to enter the unavailable state, where the unavailable state is used to indicate that the target cluster for executing the storage service and the storage nodes in the target cluster enter the non-working state.

[0112] S504. Based on the preset backup instruction, back up the configuration information of the storage node.

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

[0114] S505. Based on the pre-set node restart instruction, control the storage node to enter the startup state from the non-operating state.

[0115] According to the pre-set node restart instruction, forcibly start the storage node to forcibly start the storage service, and wait for the storage node to recover to the service Service 690 state indicating that the storage service has been started. By forcibly starting, the basic functions of the node can be restored to prepare for subsequent use.

[0116] S506. Based on the pre-set node exit instruction, control the storage node to exit the target cluster.

[0117] According to the pre-set node exit instruction, control the storage node to forcibly exit the target cluster and disconnect the connection with 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 pre-set node execution instruction, control the storage node to enter the candidate state.

[0119] According to the pre-set node execution instruction, stop the storage service, release the storage node resources, and wait for the storage node to enter the candidate Candidate state. The candidate Candidate state is used to indicate that the storage service has been stopped and waiting to rejoin the cluster to prepare for re-initialization for subsequent fault recovery.

[0120] S508. Based on the pre-set cluster recovery instruction, reconfigure the storage node in the candidate state according to the backed-up configuration information of the storage node, and control the reconfigured storage node to rejoin the target cluster to make the target cluster enter the normal operation state to recover the fault of the unavailable storage service.

[0121] According to the preparation instruction in the pre-set cluster recovery instruction, load the previously backed-up configuration information of the storage node, reconfigure the storage node in the candidate state to restore the cluster configuration and ensure data consistency. And according to the running instruction in the pre-set cluster recovery instruction, control the reconfigured storage node to rejoin the target cluster. After the storage node recovers to the Active state, the target cluster resumes normal operation.

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

[0123] After the failure recovery, obtain the current permission information of each resource type in the second user-defined user group and verify it.

[0124] In step S509, the process of verifying the current permission information of each resource type in the first user-defined user group is the same as that in the above embodiment. To avoid redundancy, it will not be repeated here. Correspondingly, the process of verifying the current permission information of each resource type in the second user-defined user group in step S510 will not be repeated either. Please refer to the above embodiment.

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

[0126] Further, on the basis of the above embodiment, the following embodiment is used to illustrate the permission verification process when the preset scenario type to which the target dynamic scenario belongs is the fourth type. Please refer to Figure 6 , Figure 6 FIG. is a schematic flowchart of a method for verifying permissions under the fourth type provided by an embodiment of the present application, which may include the following steps:

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

[0128] In this embodiment, the precondition is that the storage system is running normally, and the user group with the highest-level security management role SecurityAdmin has logged in to the command line interface (CLI) of the storage system, so that various operations such as creating a user-defined user group and injecting a failure can be performed.

[0129] S602. Based on the user group creation instruction, create a second user-defined user group with read-write permissions, and configure the permission information of each resource type in the second user-defined user group as read-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 here.

[0131] S603. Injection failure, which can be the failure of the target cluster being unavailable.

[0132] According to the fourth type to which the target dynamic scenario belongs, control the preset target cluster under the fourth type to enter the unavailable state.

[0133] S604. Based on the preset backup instruction, back up the configuration information of the storage nodes included in the target cluster.

[0134] According to the pre-set backup instruction, back up the configuration information of the storage nodes 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 the preset node restart instruction, control the storage node to enter the startup state from the non-working state.

[0136] According to the pre-set node restart instruction, forcibly start the storage node to forcibly start the storage service, and wait for the storage node to recover to the Active state and the mirror pair to reach 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, control the storage node to forcibly exit the target cluster and disconnect the connection with other storage nodes. By clearing the connection status with other storage nodes, it is used to prepare for subsequent cluster reconstruction.

[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 instruction, stop the storage service, release the storage node resources, and wait for the storage node to enter the candidate Candidate state. The candidate Candidate state is used to indicate that the storage service has been stopped and is waiting to rejoin the newly created new cluster subsequently, so as to make re-initialization preparations for subsequent fault recovery.

[0141] S608. Based on the preset cluster reconstruction instruction, create a new cluster.

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

[0143] S609. Based on the preset cluster restoration instruction, reconfigure the storage nodes in the candidate state according to the backed-up configuration information of the storage nodes, and control the reconfigured storage nodes to join the new cluster, so that the new cluster enters the normal operation state to recover the fault of the cluster being unavailable.

[0144] According to the preparation instruction in the pre-set cluster restoration instruction, load the configuration information of the storage nodes included in the target cluster backed up previously, reconfigure the storage nodes in the candidate state to ensure data consistency. And according to the running instruction in the pre-set cluster restoration instruction, control the reconfigured storage nodes to rejoin the new cluster. After the storage nodes resume to the Active state, the target cluster resumes normal operation.

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

[0146] S611. After the failure recovery, obtain and verify the current permission information of each resource type in the second user-defined user group.

[0147] For the specific implementation processes of step S610 and step S611, please refer to the above embodiments. To avoid redundancy, no further description will be given.

[0148] In the above embodiments of the present application, when the preset scenario type to which the target dynamic scenario belongs is the fourth type, by creating a custom user group with read-only and read-write permissions under the fourth type, injecting a failure that makes the preset target cluster in the unavailable state under the fourth type, and after the failure recovery, verifying whether the permission information of each resource type in the custom user group before and after the failure recovery is consistent with the initially configured permission information, the permission information is verified. 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 the present application, through Figure 5 and Figure 6 the embodiments shown, it is proved that the custom permission configuration can completely carry out system-level backup recovery and cross-cluster reconstruction operations to ensure business continuity.

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

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

[0152] Please refer to Figure 7 , Figure 7Schematic structural diagram of an authentication device for permissions provided by an embodiment of the present application. The authentication device for permissions includes:

[0153] An acquisition module 701, configured to acquire pre-configured user-defined user groups and permission information of each resource type in the user-defined user groups.

[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 a fault.

[0155] A processing module 702, configured to inject a fault corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, and recover the fault based on the corresponding fault recovery policy.

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

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

[0158] Wherein, 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 simultaneously, a third type for indicating that the storage service is unavailable, and a fourth type for indicating that the cluster is unavailable.

[0159] A possible implementation is that, before acquiring the pre-configured user-defined user groups and the permission information of each resource type in the user-defined user groups, the processing module 702 is further configured to:

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

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

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

[0163] A possible implementation is 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 downtime fault, inject a fault corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, and recover the fault based on the fault recovery policy corresponding to the preset scenario type. The processing module 702 is specifically configured to:

[0164] Control the preset target storage node under the first type to enter the shutdown state according to the first type to which the target dynamic scenario belongs.

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

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

[0167] A possible implementation is that when the preset scenario type to which the target dynamic scenario belongs is the second type and the failure is that multiple storage nodes in the target cluster simultaneously experience shutdown failures, according to the preset scenario type to which the target dynamic scenario belongs, inject a failure corresponding to the preset scenario type, and based on the failure recovery policy corresponding to the preset scenario type, recover the failure. The processing module 702 is specifically used for:

[0168] Control multiple storage nodes in the preset target cluster under the second type to enter the shutdown state according to the second type to which the target dynamic scenario belongs.

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

[0170] According to the forced restart instruction, control multiple storage nodes in the target cluster to enter the working state from the shutdown state to recover the failure of multiple storage nodes in the target cluster simultaneously experiencing shutdown.

[0171] A possible implementation is that when the preset scenario type to which the target dynamic scenario belongs is the third type and the failure is that the storage service is unavailable, according to the preset scenario type to which the target dynamic scenario belongs, inject a failure corresponding to the preset scenario type, and based on the failure recovery policy corresponding to the preset scenario type, recover the failure. The processing module 702 is specifically used for:

[0172] Control the preset storage service under the third type to enter the unavailable state according to the third type to which the target dynamic scenario belongs. The unavailable state is used to indicate that the target cluster executing the storage service and the storage nodes in the target cluster enter the non-working state.

[0173] Based on the preset backup instruction, back up the configuration information of the storage node.

[0174] Based on the preset node restart instruction, control the storage node to enter the startup state from the non-working state.

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

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

[0177] Based on a preset cluster recovery instruction, reconfigure the storage nodes in the candidate state according to the configuration information of the backed-up storage nodes, and control the reconfigured storage nodes to rejoin the target cluster, so that the target cluster enters the normal operation state to recover from the failure of the unavailable storage service.

[0178] A possible implementation is that when the preset scenario type to which the target dynamic scenario belongs is the fourth type and the failure is the unavailability of the target cluster, inject a failure corresponding to the preset scenario type according to the preset scenario type to which the target dynamic scenario belongs, and recover from the failure based on the failure recovery policy corresponding to the preset scenario type. The processing module 702 is specifically used for:

[0179] Control the preset target cluster under the fourth type to enter the unavailable state according to the fourth type to which the target dynamic scenario belongs.

[0180] Based on a preset backup instruction, back up the configuration information of the storage nodes included in the target cluster.

[0181] Based on a preset node restart instruction, control the storage node to enter the startup state from the non-operating state.

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

[0183] Based on a preset node execution instruction, control the storage node to enter the candidate state.

[0184] Based on a preset cluster reconstruction instruction, create a new cluster.

[0185] Based on a preset cluster restoration instruction, reconfigure the storage nodes in the candidate state according to the backed-up configuration information of the storage nodes, and control the reconfigured storage nodes to join the new cluster, so that the new cluster enters the normal operation state to recover from the failure of the unavailable cluster.

[0186] A 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 for:

[0187] Compare and verify the current permission information of each resource type in the first user-defined user group with the permission information of each resource type in the configured first user-defined user group.

[0188] If the comparison is consistent, obtain the first verification result, which is used to indicate that the permission verification of each resource type in the first user-defined user group passes.

[0189] If the comparison is inconsistent, obtain the second verification result, which is used to indicate that the permission verification of each resource type in the first user-defined user group 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 for:

[0191] Compare and verify the current permission information of each resource type in the second user-defined user group 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 for each resource type in the second user-defined user group passes.

[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 for each resource type in the second user-defined user group fails.

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

[0195] Figure 8 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As Figure 8 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. Among them, the processor 801, the memory 802, and the communication component 803 are connected through a bus 804.

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

[0197] For the specific implementation process of the processor 801, reference can be made to the above method embodiment, and its implementation principle and technical effects are similar, which will not be elaborated here in this embodiment.

[0198] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in 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 memory.

[0200] The bus may be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, the buses in the drawings of this application are not limited to only one bus or one type of bus.

[0201] The embodiments of the present application also provide a computer-readable storage medium, in which a computer program is stored, and the computer program is set to execute the steps in the embodiments of any of the above-mentioned permission verification methods when running.

[0202] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drives, read-only memories (ROMs), random access memories (RAMs), mobile hard disks, magnetic disks, or optical discs and other various media that can store computer programs.

[0203] The embodiments of the present application also provide a computer program product, the above computer program product includes a computer program, and when the computer program is executed by a processor, the steps in the embodiments of any of the above-mentioned permission verification methods are implemented.

[0204] Embodiments of the present application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, where the computer program, when executed by a processor, implements the steps in the embodiments of any of the above-mentioned permission verification methods.

[0205] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this article can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0206] The above has introduced in detail a permission verification method, an electronic device, a storage medium, and a program product provided by this application. Specific examples are used in this article to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for verifying permissions, characterized in that, Including: Obtain a pre-configured user-defined user group and permission information for each resource type in the user-defined user group; Obtain a target dynamic scenario to be verified, where the target dynamic scenario is used to inject a fault; According to the preset scenario type to which the target dynamic scenario belongs, inject a fault corresponding to the preset scenario type, and based on the corresponding fault recovery policy, recover the fault; After the fault is recovered, obtain the current permission information for each resource type in the user-defined user group; Compare and verify 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 simultaneously, 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 for each resource type in the user-defined user group, it further includes: Based on a user group creation instruction, create a first user-defined user group with read-only permissions and a second user-defined user group with read-write permissions. The first user-defined user group and the first user-defined user group include multiple resource types; Configure the permission information for each resource type in the first user-defined user group as read-only permissions; Configure the permission information for each resource type in the second user-defined user group as read-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 downtime fault, the 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 the fault recovery policy corresponding to the preset scenario type includes: According to the first type to which the target dynamic scenario belongs, control a preset target storage node under the first type to enter a downtime state; In response to a user's operation, obtain a restart instruction for the target storage node; According to the restart instruction, control the target storage node to enter a working state from the downtime state to recover the target storage node downtime fault.

4. The method according to claim 2, wherein When the preset scenario type to which the target dynamic scenario belongs is the second type and the fault is a downtime fault of multiple storage nodes in a target cluster occurring simultaneously, the 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 the fault recovery policy corresponding to the preset scenario type includes: According to the second type to which the target dynamic scenario belongs, control multiple storage nodes in a preset target cluster under the second type to enter a downtime state; In response to a user's operation, obtain a forced restart instruction for the target cluster; According to the forced restart instruction, control multiple storage nodes in the target cluster to enter a working state from the downtime state to recover the fault of multiple storage nodes in the target cluster occurring simultaneously in downtime.

5. The method according to claim 2, wherein When the preset scenario type to which the target dynamic scenario belongs is the third type and the fault is that the storage service is unavailable, 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 the fault recovery policy corresponding to the preset scenario type includes: Controlling a preset storage service under the third type to enter an unavailable state according to the third type to which the target dynamic scenario belongs, where the unavailable state is used to indicate that the target cluster executing the storage service and the storage nodes in the target cluster enter a non-operating state; Backing up the configuration information of the storage node based on a preset backup instruction; Controlling the storage node to enter a startup state from the non-operating state based on a preset node restart instruction; Controlling the storage node to exit the target cluster based on a preset node exit instruction; Controlling the storage node to enter a candidate state based on a preset node execution instruction; Based on a preset cluster recovery instruction, reconfiguring the storage node in the candidate state according to the backed-up configuration information of the storage node, and controlling the reconfigured storage node to rejoin the target cluster so that the target cluster enters a normal operation state to recover the fault of the unavailable storage service.

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 that the target cluster is unavailable, 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 the fault recovery policy corresponding to the preset scenario type includes: Controlling a preset target cluster under the fourth type to enter an unavailable state according to the fourth type to which the target dynamic scenario belongs; Backing up the configuration information of the storage nodes included in the target cluster based on a preset backup instruction; Controlling the storage node to enter a startup state from a non-operating state based on a preset node restart instruction; Controlling the storage node to exit the target cluster based on a preset node exit instruction; Controlling the storage node to enter a candidate state based on a preset node execution instruction; Creating a new cluster based on a preset cluster reconstruction instruction; Based on a preset cluster restoration instruction, reconfiguring the storage node in the candidate state according to the backed-up configuration information of the storage node, and controlling the reconfigured storage node to join the new cluster so that the new cluster enters a normal operation state to recover the fault of the unavailable cluster.

7. The method according to any one of claims 2-6, characterized in that, Comparing and validating the current permission information with the configured permission information to obtain a validation result includes: Comparing and validating 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, obtaining a first validation result, where the first validation result is used to indicate that the permission verification of each resource type in the first user-defined user group passes; If the comparison is inconsistent, a second verification result is obtained, and the second verification result is used to indicate that the permission verification for each resource type in the first user-defined user group fails.

8. The method according to any one of claims 2-6, characterized in that, The comparison and verification of 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 second user-defined user group with the permission information of each resource type in the configured 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 for each resource type in the second user-defined user group passes; If the comparison is inconsistent, a fourth verification result is obtained, and the fourth verification result is used to indicate that the permission verification for each resource type in the second user-defined user group fails.

9. An electronic device, characterized in that, Including: A memory for storing a computer program; A processor for implementing the steps of the permission verification method according to any one of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program implements the steps of the permission verification method according to any one of claims 1 to 8 when executed by a processor.

11. A computer program product, comprising a computer program, characterized in that, The computer program implements the steps of the permission verification method according to any one of claims 1 to 8 when executed by a processor.

Images