Permission verification method and apparatus, device and cluster

Abstract

The present application relates to the technical field of storage. Disclosed are a permission verification method and apparatus, a device and a cluster. The method is applied to an object storage service node, a target object stored in the node is mapped to a target node on a directory tree, and identifiers of the target object and the target node are target identifiers. Upon receiving an operation request comprising target identifiers, a node determines an operation permission of the operation request on the basis of a file ACL of the target identifiers and a file user identifier associated with the operation request, and determines a permission verification result on the basis of the operation permission of the operation request and a target operation type comprised in the operation request. Since a file ACL comprises a file user identifier and a file permission, on the basis of the file ACL, a node can provide for an operation request of a target node indicated by a target identifier a fine-grained permission verification conforming to file semantics, thereby improving the accuracy of permission verification of the operation request, and thus improving the security and reliability of the file service provided by the node.

Description

Permission verification method, device, equipment and cluster

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on August 1, 2023, with application number 202310960669.4 and application name “A method, device and other equipment for storing data”, and the Chinese patent application filed with the State Intellectual Property Office on November 28, 2023, with application number 202311609991.9 and application name “Authorization verification method, device, equipment and cluster”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of storage technology, and in particular to a permission verification method, apparatus, device, and cluster. Background Art

[0003] File storage stores data as files on file storage service nodes. Users can access files stored on these nodes through the file interface provided by the file storage service nodes. Object storage stores data as objects on object storage service nodes. Users can access objects stored on these nodes through the object interface provided by the object storage service nodes.

[0004] Currently, to accommodate certain applications that can only access data through file interfaces (referred to as file applications), object storage service nodes provide object-based file services. This means that file applications can access objects stored on the object storage service nodes through the file interfaces provided by the object storage service nodes. Ensuring the security and reliability of the file services provided by object storage service nodes has become a pressing technical challenge.

[0005] Summary of the Invention

[0006] The present application provides a permission verification method, apparatus, device, and cluster, which enable object storage service nodes to provide permission verification that conforms to file semantics, thereby improving the security and reliability of file services provided by object storage service nodes.

[0007] In a first aspect, a permission verification method is provided, which is used for an object storage service node, wherein a target object is stored in a storage bucket of the object storage service node, and the object storage service node is used to map the target object to a target node on a directory tree, where the target node is a target file or a target directory, and identifiers of the target object and the target node are both target identifiers; the method includes: the object storage service node receives an operation request, where the operation request includes a target identifier and a target operation type; the object storage service node determines the operation permission of the operation request based on a file access control list (ACL) of the target identifier and a file user identifier associated with the operation request, where the file ACL of the target identifier includes at least one file user identifier and at least one file permission of the file user identifier; the object storage service node determines a permission verification result based on the operation permission of the operation request and the target operation type, where the permission verification result is verification success or verification failure.

[0008] In this solution, after the object storage service node receives an operation request for a target node or target object indicated by a target identifier, it determines the operation permission corresponding to the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request, and determines the permission verification result based on the relationship between the operation permission corresponding to the operation request and the target operation type. Since the file ACL includes elements that represent the file user, such as the file user identifier (such as uid, gid, etc.), file permissions (such as r, w, x, etc.), and elements that represent the file permissions, the object storage server node can not only provide fine-grained permission verification that conforms to file semantics for the operation request of the target node indicated by the target identifier based on the file ACL, thereby improving the accuracy of the permission verification of the operation request of the target node, and further improving the security and reliability of the file service provided by the object storage service node, but also provide permission verification that conforms to file semantics for the operation request of the target object indicated by the target identifier, thereby increasing the diversity of verification methods for the operation request of the target object, and further improving the user experience.

[0009] In one possible implementation, the object storage service node determines the operation permissions of the operation request based on the file access control list (ACL) of the target identifier and the file user identifier associated with the operation request, including: the object storage service node determines the file permissions of the file user identifier associated with the operation request based on the file ACL of the target identifier; and the object storage service node determines the file permissions of the file user identifier associated with the operation request as the operation permissions of the operation request. In this implementation, the file permissions of the file user identifier associated with the operation request are directly determined as the operation permissions of the operation request, which helps improve the efficiency of permission verification.

[0010] In another possible implementation, the object storage service node determines the operation permission of the operation request based on the file access control list (ACL) of the target identifier and the file user identifier associated with the operation request, including: the object storage service node determines the file permission of the file user identifier associated with the operation request based on the file ACL of the target identifier; the object storage service node determines the object permission of the object user identifier associated with the operation request based on the object ACL of the target identifier; the object ACL of the target identifier includes at least one object user identifier and at least one object permission of the object user identifier; the object storage service node determines the minimum permission among the file permission of the file user identifier associated with the operation request and the object permission of the object user identifier associated with the operation request as the operation permission of the operation request. In this implementation, the minimum permission among the file permission of the file user identifier associated with the operation request and the object permission of the object user identifier associated with the operation request is determined as the operation permission of the operation request, which helps to improve the reliability of permission verification.

[0011] In another possible implementation, the operation request includes a target file user identifier, and the object user identifier corresponding to the target file user identifier is the object user identifier associated with the operation request; the object storage service node determines the object permissions of the object user identifier associated with the operation request based on the object ACL of the target identifier, including: the object storage service node determines the object user identifier corresponding to the target file user identifier as the target object user identifier based on the user mapping relationship, and the user mapping relationship includes the correspondence between the target object user identifier and the target file user identifier; the object storage service node determines the object permissions of the target object user identifier based on the object ACL of the target identifier; the object permissions of the target object user identifier are the object permissions of the object user identifier associated with the operation request. In this implementation, when a user sends an operation request through the file interface provided by the object storage service node, the object storage service node can determine the object permissions of the object user identifier associated with the operation request based on the user mapping relationship and the object ACL, which helps to increase the diversity of permission types related to the operation request.

[0012] In another possible implementation, the method further includes: if the target file user identifier is not included in the user mapping relationship, the object storage service node sends a first response message in response to the operation request, where the first response message indicates that the user does not have permission. This helps the user understand the permission verification result.

[0013] In another possible implementation, the operation request includes a target object user identifier, where the target object user identifier is the object user identifier associated with the operation request; and the object storage service node determines the object permissions of the object user identifier associated with the operation request based on the object ACL of the target identifier, including: the object storage service node determines the object permissions of the target object user identifier based on the object ACL of the target identifier; and the object permissions of the target object user identifier are the object permissions of the object user identifier associated with the operation request. In this implementation, when a user sends an operation request through an object interface provided by the object storage service node, the object storage service node can determine the object permissions of the object user identifier managed by the operation request based on the object ACL. This helps to increase the diversity of permission types associated with the operation request.

[0014] In another possible implementation, the operation request includes a target file user identifier, where the target file user identifier is the file user identifier associated with the operation request; the object storage service node determines the file permissions of the file user identifier associated with the operation request based on the file ACL of the target identifier, including: the object storage service node determines the file permissions of the target file user identifier based on the file ACL of the target identifier; the file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request. In this implementation, when a user sends an operation request through the file interface provided by the object storage service node, the object storage service node can determine the file permissions of the file user identifier associated with the operation request based on the file ACL. This helps to increase the diversity of permission types related to the operation request.

[0015] In another possible implementation, the operation request includes a target object user identifier, and the file user identifier corresponding to the target object user identifier is the file user identifier associated with the operation request; the object storage service node determines the file permissions of the file user identifier associated with the operation request based on the file ACL of the target identifier, including: the object storage service node determines the file user identifier corresponding to the target object user identifier as the target file user identifier based on the user mapping relationship, and the user mapping relationship includes the correspondence between the target file user identifier and the target object user identifier; the object storage service node determines the file permissions of the target file user identifier based on the file ACL of the target identifier; the file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request. In this implementation, when a user sends an operation request through the object interface provided by the object storage service node, the object storage service node can determine the file permissions of the file user identifier managed by the operation request based on the user mapping relationship and the object ACL, which helps to increase the diversity of permission types related to the operation request.

[0016] In another possible implementation, the method further includes: if the target object user identifier is not included in the user mapping, the object storage service node sends a second response message in response to the operation request, where the second response message indicates that the permission is denied. This helps the user understand the permission verification result.

[0017] In another possible implementation, the object storage service node determines the permission verification result based on the operation permission and target operation type corresponding to the operation request, including: if the operation permission corresponding to the operation request includes the target operation type, determining that the permission verification result is a successful verification; if the operation permission corresponding to the operation request does not include the target operation type, determining that the permission verification result is a failed verification.

[0018] In another possible implementation, the method further includes: if the permission check result is successful, the object storage service node processes the operation request. This helps to ensure the security of objects stored by the object storage service node.

[0019] In another possible implementation, the method further includes: if the permission verification result is successful, the object storage service node returns the permission verification result according to the operation request. In this way, when the permission verification is successful, it helps the user to promptly understand the permission verification status.

[0020] In another possible implementation, the method further includes: if the permission check result indicates a failure, the object storage service node returns the permission check result based on the operation request. This helps the user promptly understand the permission check status when the permission check fails, so that the user can change the access policy for the target node or target object indicated by the target identifier.

[0021] In another possible implementation, when the target node is a target file, the target operation type includes a read operation, a write operation, or a delete operation; when the target node is a target directory, the target operation includes a read operation, a create operation, a delete operation, a move operation, or a rename operation.

[0022] It should be noted that the object storage service node in the first aspect can also be used to execute any of the methods provided in the second aspect below.

[0023] In a second aspect, a permission setting method is provided, which is applied to an object storage service node, wherein a target object is stored in a storage bucket of the object storage service node, and the object storage service node is used to map the target object to a target node on a directory tree, wherein the target node is a target file or a target directory, and the identifiers of the target object and the target node are both target identifiers; the method includes: the object storage service node receives a file permission setting request, the file permission setting request includes a target identifier and a file ACL of the target identifier, the file ACL includes at least one file user identifier and file permissions of at least one file user identifier; the object storage service node stores the file ACL of the target identifier in the object storage service node according to the target identifier; the file ACL of the target identifier is used to determine the file permissions of the file user identifier associated with the operation request.

[0024] In this solution, the object storage service node provides the function of setting file permissions. After receiving the file permission setting request, the object storage service node stores the file ACL in the permission setting request in the object storage service node based on the target identifier in the permission setting request, thereby configuring the file ACL for the target object indicated by the target identifier. Since the file ACL includes the file user identifier (such as: uid, gid, etc.) and the file permissions (such as: r, w, x, etc.), it is possible to configure the elements used to characterize the file user and the elements used to characterize the file permissions for the target object, thereby making the access control policy (ACP) of the target object more consistent with the file semantics, and thus enabling the object storage server node to provide fine-grained permission verification that conforms to the file semantics.

[0025] In a possible implementation, the method further includes: the object storage service node receives a mapping configuration request, the mapping configuration request includes a user mapping relationship, the user mapping relationship includes a correspondence between at least one file user identifier and at least one object user identifier; the object storage service node stores the user mapping relationship; wherein the user mapping relationship is used to determine the file user identifier corresponding to the object user identifier carried in the operation request, or the user mapping relationship is used to determine the object user identifier corresponding to the file user identifier carried in the operation request.

[0026] In this implementation, when a user sends an operation request through the object interface provided by the object storage service node, the operation request carries the object user identifier. By storing the user mapping relationship, the object storage service node can determine the file user identifier corresponding to the object user identifier carried in the operation request through the user mapping relationship, thereby achieving permission verification that complies with file semantics through the file user identifier corresponding to the object user identifier and the file ACL when the user accesses the object through the object interface.

[0027] In another possible implementation, the object storage service node receives a file permission update request, which includes a target identifier, an updated file ACL, and a setting type for updating the file ACL; the setting type includes at least one of a new type, an overwrite type, a change type, and a deletion type; the object storage service node updates the file ACL of the target identifier based on the target identifier, the updated file ACL, and the setting type for updating the file ACL.

[0028] In this implementation, the object storage service node provides a file ACL update function. In this way, after setting the file ACL for the first time, the file ACL can be modified by updating the file ACL, which helps to improve the convenience of file permission setting.

[0029] In another possible implementation, a file ACL includes one or more access control entries (ACEs); updating the file ACL of a target identifier includes updating one or more ACEs in the file ACL; an ACE includes a file user identifier and file permissions for the file user identifier. In this implementation, the object storage service node supports updating one or more ACEs in the file ACL, which helps improve update accuracy.

[0030] In another possible implementation, the file permission setting request includes the file ACL setting type, and the file ACL setting type includes a new type. This helps ensure the format uniformity of the file permission update request and the file permission setting request, thereby helping to reduce the user's operation difficulty.

[0031] In another possible implementation, the object storage service node receives a file permission setting request, including: the object storage service node receiving the file permission setting request via an object ACL setting interface, where the object ACL setting interface is used to set an object ACL for a target object. In this implementation, using the object ACL setting interface provided by the object storage service node to receive the file ACL not only helps reduce permission setting costs but also helps improve the user experience.

[0032] In another possible implementation, the object storage service node stores an access control policy including a target object, the access control policy including an object ACL of the target object, the object ACL including at least one object user identifier and object permissions of at least one object user identifier; the object storage service node stores the file ACL of the target identifier in the object storage service node according to the target identifier, including: the object storage service node writes the file ACL of the target identifier into the access control policy of the target object according to the target identifier.

[0033] In this implementation, the file ACL is written into the access control policy of the target object. In this way, when an operation request is received, the object storage service node can determine the object permissions and file permissions related to the operation request by reading a file (i.e., the access control policy), which helps to improve efficiency.

[0034] In another possible implementation, the method also includes: the object storage service node receives a file permission management request; the file permission management request includes a target identifier, and the file permission management request is used to request management of the file ACL of the target identifier; the object storage service node manages the file ACL of the target identifier based on the file permission management request and the target identifier; and returns a third response information based on the file permission management request, and the third response information is used to indicate the management result of the file ACL.

[0035] In this implementation, the object storage service node provides users with file ACL management functions, thereby managing the ACL of files stored on the object storage service node.

[0036] In another possible implementation, the file permission management request includes a file permission query request; the method further includes: the object storage service node receiving the file permission query request, the file permission query request including a target identifier; and the object storage service node returning a file ACL for the target identifier in response to the file permission query request. In this implementation, the object storage service node provides a file ACL query function for the user, thereby enabling the query of the file ACL stored on the object storage service node.

[0037] In another possible implementation, the method further includes: the object storage service node receiving a file permission deletion request, the file permission deletion request including a target identifier; and the object storage service node deleting the file ACL associated with the target identifier in response to the file permission deletion request. In this implementation, the object storage service node provides a file ACL deletion function for the user, thereby enabling deletion of the file ACL stored on the object storage service node.

[0038] It should be noted that the object storage service node in the second aspect can also be used to execute any of the methods provided in the first aspect above.

[0039] In a third aspect, a permission setting method is provided for an electronic device; the method includes: obtaining a file ACL of a target identifier; the file ACL of the target identifier includes at least one file user identifier and file permissions of at least one file user identifier; sending a file permission setting request to an object storage service node; the permission setting request includes the target identifier and the file ACL of the target identifier.

[0040] In this solution, based on the file permission setting function provided by the object storage service node, when a user wants to set file permissions (i.e., permissions that conform to file semantics) for a target node or target object indicated by a target identifier, the user can obtain the file ACL of the target identifier through an electronic device and send a file permission setting request to the object storage service node. The request includes the target identifier (i.e., the identifier of the target node and target object) and the file ACL of the target identifier, which is used to request the configuration of the file ACL for the target object stored on the object storage service node. Since the file ACL includes the file user identifier (such as uid, gid, etc.) and the file permissions (such as r, w, x, etc.), it is possible to configure the target object with elements for representing the file user and elements for representing the file permissions, thereby making the ACP of the target object more consistent with file semantics, and further enabling the object storage server node to provide fine-grained permission verification that conforms to file semantics.

[0041] In one possible implementation, obtaining a file ACL for a target identifier includes: displaying a first interface; the first interface includes a first control for indicating a target object / target node; in response to a triggering operation on the first control, displaying a second interface, the second interface includes a second control for indicating a file ACL; and obtaining the file ACL for the target identifier according to the second control on the second interface. In this implementation, obtaining the file ACL through the second control on the second interface visualizes the acquisition process, helping to improve operational convenience and user experience.

[0042] In another possible implementation, the method further includes: obtaining a user mapping relationship; the user mapping relationship includes a correspondence between at least one file user identifier and at least one object user identifier; and sending the user mapping relationship to the object storage service node.

[0043] In this implementation, since when a user sends an operation request through an object interface, the operation request carries an object user identifier, by providing a user mapping relationship for the object storage service node, the object storage service node can determine the file user identifier of the object user identifier carried in the operation request through the user mapping relationship, thereby achieving permission verification that complies with file semantics through the file user identifier corresponding to the object user identifier and the file ACL when the user accesses the object through the object interface.

[0044] In another possible implementation, obtaining the user mapping relationship includes: displaying a third interface; the third interface includes a third control and a fourth control corresponding to the third control, the third control is used to indicate the object user identifier, and the fourth control is used to indicate the file user identifier; obtaining the user mapping relationship based on the third control and the fourth control corresponding to the third control.

[0045] In this implementation, the third control and the fourth control corresponding to the third control obtain the user mapping relationship, thereby visualizing the acquisition process, which helps to improve operational convenience and user experience.

[0046] In another possible implementation, sending a file permission setting request to an object storage service node includes: sending a file permission setting request to the object storage service node according to an object ACL setting interface provided by the object storage service node; the object ACL setting interface is an interface for setting the object ACL of the target object.

[0047] In this implementation, the object ACL setting interface provided by the object storage service node is used to send the file ACL to the object storage service node, which not only helps to reduce the cost of permission setting, but also helps to improve the user experience.

[0048] In another possible implementation, the file permission setting request includes a file ACL setting type, and the file ACL setting type includes a new addition type.

[0049] In another possible implementation, the method further includes: obtaining an updated file ACL; sending a file permission update request to an object storage service node, where the file permission update setting request includes a target identifier, an updated file ACL, and a setting type for updating the file ACL; the setting type for updating the file ACL includes at least one of a new addition type, a deletion type, an overwrite type, and a change type.

[0050] In this implementation, the object storage service node provides users with the function of updating file ACLs (such as adding, deleting, overwriting, and changing). This helps to improve the flexibility and convenience of file ACL settings.

[0051] In another possible implementation, the method also includes: sending a file permission management request to the object storage service node; the permission management request includes a target identifier, and the permission management request is used to request management of the file ACL of the target identifier; receiving a third response information, and the third response information is used to indicate the management result of the file ACL.

[0052] In this implementation, the object storage service node provides users with file ACL management functions, allowing users to manage the file ACLs stored on the object storage service node (such as querying, deleting, etc.).

[0053] In another possible implementation, the file permission management request includes a file permission query request; the method also includes: sending a file permission query request to an object storage service node, the file permission query request including a target identifier; and receiving the file ACL of the target identifier sent by the object storage service node.

[0054] In this implementation, the object storage service node provides users with a file ACL query function, allowing users to query the file ACL stored on the object storage service node.

[0055] In another possible implementation, the file permission management request includes a file permission deletion request; the method also includes: sending a file permission deletion request to the object storage service node, the file permission deletion request includes a target identifier; receiving a fourth response message sent by the object storage service node, the fourth response message is used to indicate the deletion result of the file ACL of the target identifier.

[0056] In this implementation, the object storage service node provides users with a file ACL deletion function, allowing users to delete the file ACL stored on the object storage service node.

[0057] In a fourth aspect, a permission verification method is provided, which is applied to an object storage system, the object storage system including an object storage service node and an electronic device, the target object is stored in a storage bucket of the object storage service node, the object storage service node is used to map the target object to a target node on a directory tree, the target node is a target file or a target directory, and the identifiers of the target object and the target node are both target identifiers; the method includes: the electronic device sends an operation request; the operation request includes a target identifier and a target operation type; the object storage service node receives the operation request; the object storage service node determines the operation permission corresponding to the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request; the file ACL of the target identifier includes at least one file user identifier and the file permission of at least one file user identifier; the object storage service node determines the permission verification result based on the operation permission corresponding to the operation request and the target operation type; the permission verification result is verification success or verification failure.

[0058] In the fourth aspect, the object storage service node can also be used to execute any possible implementation method provided in the first aspect above.

[0059] In a fifth aspect, a permission setting method is provided, which is applied to an object storage system, the object storage system including an object storage service node and an electronic device, the target object is stored in a storage bucket of the object storage service node, the object storage service node is used to map the target object to a target node on a directory tree, the target node is a target file or a target directory, and the identifiers of the target object and the target node are both target identifiers; the method includes: the electronic device obtains a file ACL of the target identifier; the file ACL includes at least one file user identifier and at least one file permission of the file user identifier; the electronic device sends a file permission setting request to the object storage service node; the file permission setting request includes the target identifier and the file ACL of the target identifier; the object storage service node receives the file permission setting request; the object storage service node stores the file ACL of the target identifier on the object storage service node according to the target identifier; the file ACL of the target identifier is used to determine the file permission of the file user identifier associated with the operation request.

[0060] In the fifth aspect, the object storage service node can also be used to execute any possible implementation method provided in the second aspect above, and the electronic device can also be used to execute any possible implementation method provided in the third aspect above.

[0061] In a sixth aspect, a permission verification device is provided, which includes: a functional module for executing any one of the methods provided in the first aspect, wherein the actions performed by each functional module are executed by hardware or by hardware executing corresponding software. For example, the permission verification device may include a receiving module and a permission module; the receiving module is used to receive an operation request; the operation request includes a target identifier and a target operation type; the permission module is used to determine the operation permission corresponding to the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request; the file ACL of the target identifier includes at least one file user identifier and the file permission of at least one file user identifier; the permission module is also used to determine the permission verification result based on the operation permission corresponding to the operation request and the target operation type; the permission verification result is verification success or verification failure.

[0062] In a seventh aspect, a permission setting device is provided, the device comprising: a functional module for executing any one of the methods provided in the second aspect, wherein the actions performed by each functional module are executed by hardware or by hardware executing corresponding software implementations. For example, the permission setting device may comprise a receiving module and a permission module; the receiving module is configured to receive a file permission setting request; the file permission setting request comprises a target identifier and a file ACL of the target identifier, the file ACL comprising at least one file user identifier and file permissions of at least one file user identifier; the permission module is configured to store the file ACL of the target identifier in an object storage service node based on the target identifier; the file ACL of the target identifier is used to determine the file permissions of the file user identifier associated with the operation request.

[0063] In an eighth aspect, a permission setting device is provided, the device comprising: functional modules for executing any one of the methods provided in the third aspect, wherein the actions performed by each functional module are executed by hardware or by hardware executing corresponding software implementations. For example, the permission setting device may include an acquisition module and a sending module; the acquisition module is configured to acquire a file ACL for a target identifier; the file ACL includes at least one file user identifier and at least one file permission for the file user identifier; the sending module is configured to send a file permission setting request to an object storage service node; the file permission setting request includes the target identifier and the file ACL for the target identifier.

[0064] In a ninth aspect, an object storage system is provided, which includes an object storage service node and an electronic device, wherein a target object is stored in a storage bucket of the object storage service node, and the object storage service node is used to map the target object to a target node on a directory tree, where the target node is a target file or a target directory, and the identifiers of the target object and the target node are both target identifiers; the electronic device is used to send an operation request; the operation request includes a target identifier and a target operation type; the object storage service node is used to receive the operation request; the object storage service node is also used to determine the operation permission corresponding to the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request; the file ACL of the target identifier includes at least one file user identifier and the file permission of at least one file user identifier; the object storage service node is also used to determine the permission verification result based on the operation permission corresponding to the operation request and the target operation type; the permission verification result is verification success or verification failure.

[0065] In the ninth aspect, the object storage service node can also be used to execute any possible implementation method provided in the first aspect above.

[0066] In a tenth aspect, an object storage system is provided, which includes an object storage service node and an electronic device, wherein a target object is stored in a storage bucket of the object storage service node, and the object storage service node is used to map the target object to a target node on a directory tree, where the target node is a target file or a target directory, and the identifiers of the target object and the target node are both target identifiers; the electronic device is used to obtain a file ACL of the target identifier; the file ACL includes at least one file user identifier and at least one file permission of the file user identifier; the electronic device is also used to send a file permission setting request to the object storage service node; the file permission setting request includes a target identifier and a file ACL of the target identifier; the object storage service node is used to receive the file permission setting request; the object storage service node is also used to store the file ACL of the target identifier in the object storage service node according to the target identifier; the file ACL of the target identifier is used to determine the file permission of the file user identifier associated with the operation request.

[0067] In the tenth aspect, the object storage service node can also be used to execute any possible implementation method provided by the second aspect above, and the electronic device can also be used to execute any possible implementation method provided by the third aspect above.

[0068] In the eleventh aspect, a processor is provided, which is used to execute any one of the methods provided in the first aspect, or to execute any one of the methods provided in the second aspect.

[0069] In the twelfth aspect, a processor is provided, which is used to execute any one of the methods provided in the third aspect.

[0070] In the thirteenth aspect, a chip is provided, comprising: a processor and a power supply circuit; the power supply circuit is used to supply power to the chip; the processor is used to execute any one of the methods provided in the first aspect above, or to execute any one of the methods provided in the second aspect above.

[0071] In the fourteenth aspect, a chip is provided, comprising: a processor and a power supply circuit; the power supply circuit is used to supply power to the chip; and the processor is used to execute any one of the methods provided in the third aspect above.

[0072] In the fifteenth aspect, a computing device is provided, which includes a processor and a memory; the processor of the computing device is used to execute instructions stored in the memory of the computing device, so that the computing device executes any one of the methods provided in the first aspect above, or executes any one of the methods provided in the second aspect above.

[0073] In the sixteenth aspect, an electronic device is provided, which includes a processor and a memory; the processor of the electronic device is used to execute instructions stored in the memory of the electronic device, so that the electronic device executes any one of the methods provided in the third aspect above.

[0074] In the seventeenth aspect, a computer-readable storage medium is provided, comprising: computer program instructions. When the computer program instructions are executed by a computing device, the computing device executes any one of the methods provided in the first aspect above, or executes any one of the methods provided in the second aspect above.

[0075] In the eighteenth aspect, a computer-readable storage medium is provided, comprising: computer program instructions. When the computer program instructions are executed by an electronic device, the electronic device executes any one of the methods provided in the third aspect above.

[0076] In the nineteenth aspect, a computer program product comprising instructions is provided, which, when the instructions are executed on a computing device, causes the computing device to execute any one of the methods provided in the first aspect, or any one of the methods provided in the second aspect.

[0077] In the twentieth aspect, a computer program product comprising instructions is provided, which, when executed by an electronic device, enables the electronic device to execute any one of the methods provided in the third aspect.

[0078] Among them, the technical effects brought about by any design method in the fourth to twentieth aspects can refer to the technical effects brought about by the different design methods in the above-mentioned first to third aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0079] FIG1A is a schematic diagram of a system architecture provided in an embodiment of the present application;

[0080] FIG1B is a schematic diagram of another system architecture provided in an embodiment of the present application;

[0081] FIG2 is a flowchart of a permission verification method provided in an embodiment of the present application;

[0082] FIG3 is a flowchart of another permission verification method provided in an embodiment of the present application;

[0083] FIG4 is a flowchart of a method for checking permissions for a read request provided in an embodiment of the present application;

[0084] FIG5 is a flowchart of a method for verifying permissions of a write request provided in an embodiment of the present application;

[0085] FIG6 is a flowchart of a method for verifying permissions for a deletion request provided in an embodiment of the present application;

[0086] FIG7 is a flowchart of a method for setting file permissions provided in an embodiment of the present application;

[0087] FIG8A is a schematic diagram of obtaining a file ACL according to an embodiment of the present application;

[0088] FIG8B is a schematic diagram of another method for obtaining a file ACL according to an embodiment of the present application;

[0089] FIG9 is a flowchart of a method for updating file permissions provided in an embodiment of the present application;

[0090] FIG10 is a flowchart of a file permission management method provided in an embodiment of the present application;

[0091] FIG11A is a schematic diagram of a file permission query provided in an embodiment of the present application;

[0092] FIG11B is a schematic diagram of deleting file permissions provided in an embodiment of the present application;

[0093] FIG12 is a flowchart of a method for setting a user mapping relationship provided in an embodiment of the present application;

[0094] FIG13A is a schematic diagram of obtaining a user mapping relationship according to an embodiment of the present application;

[0095] FIG13B is a schematic diagram of another method for obtaining a user mapping relationship according to an embodiment of the present application;

[0096] FIG14 is a schematic diagram of an authority verification device provided in an embodiment of the present application;

[0097] FIG15 is a schematic diagram of a permission setting device provided in an embodiment of the present application;

[0098] FIG16 is a schematic diagram of a permission setting device provided in an embodiment of the present application;

[0099] FIG17 is a schematic diagram of a computing device provided in an embodiment of the present application;

[0100] FIG18 is a schematic diagram of a computing device cluster provided in an embodiment of the present application;

[0101] FIG19 is a connection diagram of a computing device cluster provided in an embodiment of the present application;

[0102] FIG20 is a schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0103] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0104] In the description of the embodiments of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; "and / or" in the present application is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural.

[0105] Furthermore, in the description of the embodiments of the present application, unless otherwise specified, "a plurality" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural.

[0106] In addition, to facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or execution order, and the words "first" and "second" do not necessarily mean different.

[0107] At the same time, in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0108] The following is an introduction to the relevant terms involved in the embodiments of the present application.

[0109] File system: It is the software in the operating system responsible for managing and storing file information. The file system includes the basic file system and several file subsystems. Users can remove and install file subsystems as needed.

[0110] The target tree provided by the file system includes a root directory, subdirectories, and files under the subdirectories, wherein the root directory or subdirectory may include files and next-level subdirectories.

[0111] File storage service (FSS): It stores data in the form of files on a file storage service node. The file storage service node provides a multi-level tree-like directory storage method based on the file system. The file storage service node is used to provide users with operations that conform to file semantics (i.e., file services), such as: reading files, writing files, creating files, deleting files, opening files, closing files, renaming files, and other operations. Among them, the file storage service node provides a file interface, and the file interface can indicate operations that conform to file semantics. For example, the file interface can be a portable operating system interface (POSIX), and users can access data on the file storage service node through the POSIX interface.

[0112] It should be noted that when a user accesses data through a file interface, the data may be referred to as a file.

[0113] Object storage service (OBS): It stores data in the form of objects in object storage nodes. Object storage nodes provide a flat storage method based on buckets and objects. All objects in a bucket are at the same logical level, eliminating the multi-level tree directory structure in the file storage service node. The object storage system is used to provide users with operations that conform to object semantics (i.e., object services), such as uploading objects, downloading objects, listing each object in a bucket, copying objects, moving objects, renaming objects, deleting objects, deleting each object in a bucket, deleting specified multiple objects, etc. Among them, the object storage node provides an object interface, and the object interface can indicate operations that conform to object semantics. For example, the object interface can be a representational state transfer (REST) ​​application programming interface (API). Users can access data on the object storage service node through the REST API interface.

[0114] It should be noted that when a user accesses data through an object interface, the data can be called an object.

[0115] Bucket: Also known as a bucket, it is a container used to store objects on an object storage node. Each bucket has its own attributes, such as storage category, access permissions, and region.

[0116] Object: The basic unit of data storage on an object storage node. An object is a collection of file data and its associated attribute information (also known as metadata). An object consists of a key, metadata, and data.

[0117] The key is the name of the object, also known as the object name or object name. Each object in a bucket has a unique key. Metadata is the descriptive information of the object. Metadata includes user metadata and system metadata. User metadata is user-defined object description information specified when the user uploads the object, while system metadata is automatically generated by the object storage service node. Data is the data content of the object, that is, the file data, and can also be called user data.

[0118] File permissions: refers to permissions that conform to file semantics. In the Linux system, the order of file permissions from high to low is: special permissions, ACL permissions, and ordinary permissions. Special permissions refer to the setuid, setgid, and sticky bits of files, which are used to set special permissions for files or directories and have a higher priority than ACL permissions and ordinary permissions. Ordinary permissions refer to the basic permissions of files or directories, including read, write, and execute permissions for files or directories by the owner, group, and others. ACL permissions refer to fine-grained permissions that allow users to set for individual users and user groups to access files or directories. ACL permissions are inherited from ordinary permissions and have a higher priority than ordinary permissions. Therefore, they can override the settings of ordinary permissions.

[0119] The following is an illustrative introduction to the application scenarios of the embodiments of the present application.

[0120] With the development of storage technology, object storage has been proposed to facilitate the storage of unstructured data such as movies, office documents, and images. Object storage uses a flat address space to store data, without the hierarchical structure of directories and files. Therefore, an object storage system can store large amounts of data.

[0121] Currently, to ensure compatibility with file applications, object storage service nodes provide object-based file services, essentially building file services on top of object storage. However, due to differences in storage formats, access interfaces, and permission management between objects and files, file semantics differ significantly from object semantics.

[0122] Exemplarily, file semantics uses elements such as "r, w, x" to represent file permissions, where r is used to represent read permissions, w is used to represent write permissions, and x is used to represent executable permissions. Object semantics uses elements such as "READ, READ_ACP, WRITE_ACP, FULL_CONTROL" to represent object permissions, where READ is used to represent the permission to read objects, READ_ACP is used to represent the permission to read access control policy (ACP), WRITE_ACP is used to represent the permission to write ACP, and FULL_CONTROL is used to represent all control permissions, namely READ, READ_ACP, and WRITE_ACP. In addition, file semantics uses "uid, gid" to represent file users, where uid represents a single user and gid represents a group user. Object semantics uses "ID" to represent object users, where object users do not distinguish between single users or group users.

[0123] On this basis, how to ensure the security and reliability of file services provided by object storage service nodes has become a technical problem that needs to be solved urgently.

[0124] In view of this, an embodiment of the present application provides a permission verification method for an object storage service node. After the object storage service node receives an operation request for a target node or target object indicated by a target identifier, the object storage service node determines the operation permission corresponding to the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request, and determines the permission verification result based on the relationship between the operation permission corresponding to the operation request and the target operation type. Since the file ACL includes elements that characterize the file user, such as the file user identifier (such as uid, gid, etc.), file permissions (such as r, w, x, etc.), and elements that characterize the file permissions, the object storage server node can not only provide fine-grained permission verification that conforms to file semantics for the operation request of the target node indicated by the target identifier based on the file ACL, thereby improving the accuracy of the permission verification of the operation request of the target node, thereby improving the security and reliability of the file service provided by the object storage service node, but also provide permission verification that conforms to file semantics for the operation request of the target object indicated by the target identifier, thereby improving the diversity of the verification methods for the operation request of the target object, thereby improving the user experience.

[0125] The following is an exemplary introduction to the system architecture of the embodiment of the present application.

[0126] The permission verification method and permission setting method provided in the embodiments of the present application are applicable to object storage systems.

[0127] The object storage system includes an object storage service node (Server) and a client (Client), and the client and the object storage service node can communicate.

[0128] The object storage service node can provide storage services and metadata services. The storage service is used to manage the user data of objects, and the metadata service is used to manage the metadata of objects.

[0129] In the embodiment of the present application, the object storage service node includes one or more computing devices. The metadata service and the storage service can be provided by the same computing device, or they can be provided by different computing devices, which is not limited in the embodiment of the present application.

[0130] For example, when metadata services and storage services are provided by different computing devices, the computing device used to provide storage services can be called an object storage device (OSD), and the node used to provide metadata services can be called a metadata server (MDS) device.

[0131] Optionally, the computing device may be a network device or a terminal device. The network device may include a server, etc. The server may be a single physical server, or two or more physical servers sharing different responsibilities that collaborate to implement the server's functions. Exemplarily, the server may be a blade server, a high-density server, a rack server, or a tower server. The terminal device may include an ultra-mobile personal computer (UMPC), a laptop, a netbook, a desktop computer, an all-in-one computer, etc.

[0132] It should be noted that the above is only an exemplary description, and the embodiments of the present application do not limit the specific device form of the computing device.

[0133] In an embodiment of the present application, the object storage service node also includes a storage device, which may include one or more storage buckets, and the one or more storage buckets are used to store objects.

[0134] Exemplary storage devices may include hard disk drives (HDDs), solid state disks (SSDs), and the like. It should be noted that the form of the storage devices in the embodiments of the present application is not limited, and the above description is merely exemplary. Furthermore, the number of storage devices in the embodiments of the present application is also not limited.

[0135] In the embodiment of the present application, the storage device can be provided on the computing device, or can be provided independently of the computing device. When the storage device and the computing device are provided independently of each other, the storage device and the computing device are in communication connection.

[0136] In an embodiment of the present application, the object storage service node also includes one or more gateway devices, one or more gateway devices are connected to one or more computing devices, and one or more computing devices can communicate with the user's electronic device through one or more gateway devices.

[0137] In the embodiments of the present application, a client can be installed on a user's electronic device, which communicates with an object storage service node through the client. The user can log in to the client through the electronic device and rent a cloud storage service, such as a storage bucket, from a provider through the client. The user can then use the client to store objects in the bucket and manage and access the objects stored in the bucket.

[0138] In embodiments of the present application, an object storage service node is used to provide object services (e.g., metadata services, storage services, etc.) and file services. For example, a user can access data stored on the object storage service node through an object interface provided by the object storage service node. Furthermore, a user can access data stored on the object storage service node through a file interface provided by the object storage service node.

[0139] In an embodiment of the present application, the object storage service node stores data through storage buckets, that is, the object storage service node stores data in the form of objects in the storage buckets.

[0140] In order to make it easier for users to manage data in buckets, the object storage service node also provides a way to simulate folders: by adding " / " to the name of the object, the object is simulated as a folder on the OBS management console. For example, the object name of object 0 is abc.jpg. If object 0 needs to be simulated as a file in a folder, the object identifier of object 0 can be modified to test / abc.jpg. In this case, "test" is a simulated folder. When users list objects in a bucket through the object interface, the object identifiers obtained are separated by " / ". If there is content after the last " / ", it indicates a file, that is, the object to which the object identifier belongs indicates a file. If there is no content after the last " / ", it indicates a folder path, that is, the object to which the object identifier belongs indicates a simulated folder. For example, the object identifier of object 1 is test / , so object 1 represents a folder path.

[0141] It should be noted that, when an object is simulated as a folder, the object identifier includes the folder path and the object name. When an object is not simulated as a folder, the object identifier may be the object name.

[0142] In the embodiment of the present application, the object storage service node can map objects in a bucket to nodes in a directory tree using a hierarchical namespace. A node can be a file or a directory. An object that includes user data can be mapped to a file, and a simulated folder (i.e., an object that does not include user data) can be mapped to a directory.

[0143] It should be noted that the file can be an ordinary file including user data, and the directory can be a block device file, character device file, link file, pipe file, socket file or directory file that does not include user data. The embodiment of the present application does not limit the type of file or directory.

[0144] On this basis, after the user enables the file service feature for the object storage service node on the client, the user can access the nodes on the directory tree through the file system client (also referred to as the file client) or the object storage client (also referred to as the object client).

[0145] For example, a file system client (such as an obsfs client) is installed on the user's electronic device. The user can log in to the management platform using the file account name and password on the file system client, and access the node mapped by the object storage service node by calling the file interface provided by the object storage service node through the management platform.

[0146] As shown in FIG1A , it is a schematic diagram of a system architecture provided in an embodiment of the present application.

[0147] Referring to Figure 1A , the system architecture includes an object storage service node, an electronic device, and a client. The client is installed on the electronic device. Cloud service providers provide cloud services (e.g., object services, metadata services, and file services) to users through the object storage service node. Cloud service tenants (i.e., users) rent cloud services provided by the cloud service provider through the client on the electronic device.

[0148] Exemplarily, the electronic device may be a terminal device or a network device.

[0149] Terminal devices may include mobile phones, tablet computers, handheld computers, PCs, cellular phones, personal digital assistants (PDAs), wearable devices (such as smart watches and smart bracelets), smart home devices (such as televisions), car computers (such as on-board computers), smart screens, game consoles, headphones, AI speakers, augmented reality (AR) / virtual reality (VR) devices, ultra-mobile personal computers (UMPCs), laptops, netbooks, desktop computers or all-in-one computers, etc.

[0150] Network devices may include servers, etc. A server may be a single physical server, or two or more physical servers sharing different responsibilities and working together to implement various server functions. For example, the server may be a blade server, a high-density server, a rack server, or a tower server.

[0151] It should be noted that the above is only an exemplary description, and the embodiments of the present application do not limit the specific device form of the electronic device.

[0152] Exemplarily, the storage device of the object storage service node may include buckets 1, ..., and N, where N is a positive integer greater than 1. After a user logs in to a client through an electronic device, they can rent a bucket (e.g., bucket 1) from a cloud service provider. After renting bucket 1, the client can send objects to be stored (e.g., objects 0-4) to the object storage service node. After receiving objects 0-4, the object storage service node stores objects 0-4 in the user-rented bucket 1.

[0153] It should be noted that the embodiment of the present application does not limit the number of computing devices, the number of storage devices, and the number of storage buckets included in the object storage service node. Figure 1A is only for illustrative purposes.

[0154] As shown in FIG1B , it is a schematic diagram of another system architecture provided in an embodiment of the present application.

[0155] Referring to FIG. 1B , the object storage service node provides a service interface and a management interface, wherein the service interface is used to access data on the object storage service node, and the management interface is used to manage data on the object storage service node.

[0156] For example, users can call the service interface through the client on an electronic device to perform read and delete operations on the data on the object storage service node. In addition, users can call the management interface through the client to set permissions such as file ACLs for objects stored on the object storage service node, as well as set user mapping relationships for objects or storage buckets.

[0157] Exemplarily, an object storage service node includes an ACL Permission Check module. By running the ACL Permission Check module, the object storage service node sets file ACLs for objects and performs permission checks based on the file ACLs when users access data on the object storage service node. Furthermore, the object storage service node may also include a user management module. By running the user management module, the object storage service node sets user mappings for objects or buckets.

[0158] It should be noted that the system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0159] For ease of understanding, the following is an exemplary introduction to the permission setting method provided in the embodiment of the present application in combination with the above system architecture and accompanying drawings.

[0160] FIG2 is a flow chart showing a method for verifying permissions according to an exemplary embodiment. Exemplarily, the method for verifying permissions may include the following steps 201 to 205 .

[0161] It should be noted that the "step" in the embodiment of the present application can be abbreviated as "S" and will not be repeated later.

[0162] In an embodiment of the present application, an object storage service node stores multiple objects. Exemplarily, the multiple objects include a target object, which can be any one of the multiple objects.

[0163] Wherein, an object can be used to indicate a file or folder. When an object is used to indicate a file, the object can include user data, metadata, and an object ID. When an object is used to indicate a folder, the object can include metadata and an object ID.

[0164] The object storage service node maps multiple objects stored in the bucket to multiple nodes on the directory tree. Exemplarily, the multiple nodes include a target node, which is a node mapped based on the target object.

[0165] It should be noted that when a node is a file, the node can also be called a file node. When a node is a directory, the node can also be called a directory node.

[0166] It can be understood that an object indicating a file will be mapped to a file node on the directory tree, and an object indicating a folder will be mapped to a directory node on the directory tree.

[0167] In an embodiment of the present application, an object storage service node stores mappings between multiple objects and multiple nodes. There is a one-to-one correspondence between the multiple objects and the multiple nodes, that is, there is a mapping relationship between an object and the node to which it is mapped. For example, there is a mapping relationship between a target node and a target object.

[0168] The following describes the relationship between nodes and objects, taking the target element stored on an object storage service node as an example.

[0169] Exemplarily, an object storage service node stores a target element in a bucket as an object. The target element can be user data or a simulated folder. When a user accesses a target element using the object interface provided by the object storage service node, the target data can be referred to as a target object. When a user accesses a target element using the file interface provided by the object storage system, the target data is referred to as a target node. A target node and a target object that have a mapping relationship point to the same element (i.e., the target element).

[0170] Hereinafter, the permission verification method provided by the embodiment of the present application is exemplified by taking the target object and the target node mapped to the target object as an example, wherein the identifiers of the target object and the target node are both target identifiers.

[0171] Exemplarily, the target identifier may be represented in the form of a Uniform Resource Identifier (URI), a character string, etc., which is not limited in the embodiments of the present application.

[0172] Optionally, a first client is installed on the electronic device. When the first client sends an operation request to the object storage service node, the user identifier carried in the operation request is a file user identifier, such as uid, gid, etc.

[0173] It should be noted that the relevant description of the file user identifier will be explained in subsequent embodiments and will not be repeated here. In addition, to facilitate the distinction between users who use different clients to send operation requests to the object storage service node, the user using the first client can be referred to as the file user and will not be repeated here.

[0174] It should be noted that the first client can be a file system client, or it can be other clients that carry a file user identifier when communicating with the object storage service node. This embodiment of the present application does not impose any restrictions on this.

[0175] It should be noted that the first client in the following embodiments performs a certain operation, such as sending an operation request to the object storage service node, which can be considered as the electronic device performing a certain action in the process of running the first client, or the electronic device performing a certain operation through the first client, which will not be repeated later.

[0176] Step 201: A first client sends an operation request to an object storage service node.

[0177] The operation request indicates a target identifier. In the case where the operation request indicates a target identifier, the operation request can be used to request to perform an operation on the target node / target object indicated by the target identifier.

[0178] It should be noted that, below, the embodiment of the present application is exemplarily described by taking the operation request for requesting to perform an operation on the target node indicated by the target identifier as an example.

[0179] In one example, the operation request may include a target identifier. In another example, the operation request may include a first character, and the object storage service node may determine, based on the first character, an identifier of a node on which the operation request is requested to perform an operation as the target identifier.

[0180] It should be noted that the embodiment of the present application does not limit how the operation request indicates the target identifier, and the above is only an exemplary description.

[0181] The operation request indicates a target operation. In the case where the operation request indicates a target operation, the operation request can be used to request execution of the target operation.

[0182] Exemplarily, the operation request may include a target operation type, where the target operation type is the type of the target operation. The object storage service node may determine that the operation request is to perform the target operation based on the target operation type.

[0183] It should be noted that the embodiments of the present application do not limit how the operation request indicates the type of operation requested to be performed, and the above is merely an exemplary description.

[0184] In one example, a user logs in to a first client through an electronic device, and performs a target operation on a target node provided by a file system on the electronic device through the first client, such as a read operation, a write operation, a delete operation, etc. The first client sends an operation request to the object storage service node in response to the target operation performed by the user on the target node.

[0185] In another example, when an electronic device needs to perform a target operation on a target node while running a file application, the file application sends a request to a first client, and the first client sends an operation request to an object storage service node in response to the received request.

[0186] Exemplarily, when the target node is a file, the target operation may include a read operation, a write operation, or a delete operation, etc. When the target node is a directory, the target operation may include a read operation, a create operation, a delete operation, a move operation, or a rename operation, etc.

[0187] In an embodiment of the present application, the operation request may further include a target file user identifier. The target file user identifier is the identifier of the target file user who sends the operation request to the object storage service node via the first client. In other words, the target file user is the file user requesting the target operation to be performed on the target node.

[0188] For example, a user enters a file account name and password on a login interface of a first client displayed on an electronic device. After logging into the first client, the first client sends an operation request to an object storage service node via a file interface (e.g., a POSIX interface). The operation request carries a target file user identifier corresponding to the file account name. The electronic device may store a correspondence between the file account name and the target file user identifier.

[0189] Step 202: The object storage service node receives an operation request sent by the first client.

[0190] Exemplarily, the object storage service node may receive an operation request sent by the first client based on a file interface.

[0191] For example, if the operation request is a write request, the file interface can be write / filesystem / dir / file, where write indicates that the target operation type is a write operation and / filesystem / dir / file indicates the target identifier. If the operation request is a read request, the file interface can be read / filesystem / dir / file, where read indicates that the target operation type is a read operation. If the operation request is a delete request, the file interface can be delete / filesystem / dir / file, where delete indicates that the target operation type is a delete operation.

[0192] It should be noted that step 202 can be considered as an implementation method of "the object storage service node receiving the operation request".

[0193] Step 203: The object storage service node determines the operation permission corresponding to the operation request.

[0194] The operation permission corresponding to the operation request is the permission of the target file user on the target node, or in other words, the permission of the target file user who requests to perform the target operation on the target node on the target node.

[0195] It should be noted that the operation permission corresponding to the operation request can also be called the operation permission of the operation request, and the embodiments of the present application do not limit this.

[0196] Step 203 may include multiple implementation methods. The following is an exemplary description using Method 1 and Method 2.

[0197] Method 1: The object storage service node determines the operation permission corresponding to the operation request based on the file ACL corresponding to the target identifier and the target file user identifier included in the operation request.

[0198] In the embodiment of the present application, when the operation request includes a target file user identifier, the target file user identifier is a file user identifier associated with the operation request.

[0199] In an embodiment of the present application, the target object stored in the object storage service node is configured with a file ACL, wherein the file ACL of the target object can be stored in the object storage service node.

[0200] It should be noted that how to configure the file ACL for the target object will be described in subsequent embodiments and will not be described here in detail. For details, please refer to the embodiment shown in FIG. 7 .

[0201] In addition, since the identifier of the target object is the target identifier, the file ACL of the target object may also be referred to as the file ACL corresponding to the target identifier, or simply referred to as the file ACL of the target identifier.

[0202] In the embodiment of the present application, the file ACL refers to an ACL that uses file semantics to represent users and permissions, wherein the file ACL includes at least one file user identifier and at least one file permission corresponding to the file user identifier.

[0203] It should be noted that the embodiment of the present application does not limit the number of file user identifiers included in the file ACL. In addition, the file permission corresponding to at least one file user identifier can also be referred to as the file permission of at least one file user identifier.

[0204] The file user ID is a user ID in the file semantics, or in other words, a user ID that complies with the file semantics.

[0205] In an embodiment of the present application, the file user identifier may include at least one of a user identifier (uid) and a group identifier (gid). The user identifier is used to represent a single user / single file user, and the group identifier is used to represent a group, which may include one or more users / file users.

[0206] In this embodiment, by setting the file ACL to include a file user identifier, such as uid and gid, an element for representing the file user is added to the file ACL of the target object. That is, the user is represented using file semantics, thereby expanding the user representation method in the file ACL of the target object, making the file ACL of the target object more consistent with file semantics.

[0207] Exemplarily, the file user ID can be the ID of the user who uses the target node, or the ID of the user who created the target node. The group ID can be the ID of the group that uses the target node, or the ID of the group that created the target node. The user / group that created the target node can also be called the owner of the file.

[0208] Optionally, the file permissions are permissions in file semantics, or in other words, permissions that comply with file semantics.

[0209] In the embodiment of the present application, the file permission may include at least one of read permission (r), write permission (w) and executable permission (x).

[0210] In this embodiment, by setting the file ACL to include file permissions, such as r, w, x, etc., elements used to represent file permissions are added to the file ACL of the target object. That is, file semantics are used to represent permissions, thereby expanding the method of representing permissions in the file ACL of the target object, making the file ACL of the target object more consistent with file semantics.

[0211] It should be noted that when the target node is a file, r is used to indicate the permission to read the content of the target node. w is used to indicate the permission to edit, add, or delete the content of the target node. x is used to indicate the permission to be executed by the operating system.

[0212] When the target node is a directory, r indicates permission to read the names of files under the target node. w indicates permission to create, delete, rename, and move files / subdirectories under the target node. x indicates permission to enter the target node.

[0213] In this embodiment of the present application, when the file user ID belongs to user 1, the file permission corresponding to the file user ID is the permission of user 1 to the target node / target object. In other words, the file ACL of the target object can be used to indicate the permission of the user to whom the file user ID belongs to the target node / target object.

[0214] In the embodiment of the present application, the file ACL of the target object can be stored in the Xml Body. The following is an exemplary description of the method of representing the file user identifier and file permissions in the Xml Body.

[0215] In one example, the target object's file ACL includes <uid> 6668< / uid> and with <uid> 6668< / uid> Corresponding <permission> w< / permission> ,in, <uid> 6668< / uid> Used to represent the user ID is 6668, <permission> w< / permission> The file permission corresponding to 6668 is write permission, that is, the user to which 6668 belongs has write permission on the target node.

[0216] In another example, the target object's file ACL includes <gid> 6670< / gid> and with <gid> 6670< / gid> Corresponding <permission> rw< / permission> ,in, <gid> 6670< / gid> The group ID used to represent the group is 6670. <permission> rw< / permission> The file permissions corresponding to 6670 are read permission and write permission, that is, each user in the group to which 6670 belongs has read permission and write permission on the target node.

[0217] In yet another example, the file ACL of the target object includes <uid>other < / uid> 、 <gid> other < / gid> and with <uid> other < / uid> 、 <gid> other < / gid> Corresponding <permission> r< / permission> ,in, <uid> other < / uid> 、 <gid> other < / gid> Used to represent user ID and group ID as other. <permission> r< / permission> This field indicates that the file permission corresponding to "other" is read permission. In other words, the user to whom "other" belongs has read permission on the target node.

[0218] In yet another example, the file ACL of the target object includes <owner> <uid> 6667< / uid> <gid> 6668< / gid> < / owner> ,in, <uid> 6667< / uid> The user ID that represents the owner of the target node. <gid> 6668< / gid> The group ID that indicates the owner of the target node.

[0219] For example, the owner of the target node has all permissions, that is, r, w, x permissions. Based on this, <owner> <uid> 6667< / uid> <gid> 6668< / gid> < / owner>correspond <permission> rwx < / permission> .

[0220] It should be noted that, since the owner of the target node has all permissions, the file permissions corresponding to the identifier of the target node owner can be omitted in the file ACL of the target object, that is, <owner> <uid> 6667< / uid> <gid> 6668< / gid> < / owner> The corresponding file permissions can be omitted.

[0221] In an embodiment of the present application, determining the permissions corresponding to the operation request based on the file ACL corresponding to the target identifier and the file user identifier associated with the operation request may include: determining the file permissions corresponding to the target file user identifier based on the file ACL of the target object; and determining the file permissions corresponding to the target file user identifier as the operation permissions corresponding to the operation request.

[0222] The file permission corresponding to the target file user identifier is the file permission of the file user identifier associated with the operation request.

[0223] It should be noted that the file permissions corresponding to the target file user identifier are the file permissions of the target file user on the target node, or in other words, the file permissions of the target file user requesting to perform the target operation on the target node on the target node. In addition, the file permissions corresponding to the target file user identifier can also be called the permissions of the target file user identifier.

[0224] In an embodiment of the present application, after the object storage service node receives the operation request, it reads the file ACL of the target object based on the target identifier as the identifier of the target object, and determines the file permissions corresponding to the target file user identifier based on the file ACL of the target object, thereby realizing file permission verification for the target operation requested to be performed by the target file user.

[0225] Exemplarily, the object storage service node checks each ACE in the file ACL of the target object to determine the file permission corresponding to the target file user identifier, thereby determining the operation permission corresponding to the operation request.

[0226] For example, the target file user ID is 6668, and the target object's file ACL includes <uid> 6668< / uid> as well as <uid> 6668< / uid> Corresponding <permission> w< / permission> Based on this, the object storage service node determines that the file permission corresponding to the target file user ID is w.

[0227] It should be noted that method 1 can be considered as a specific implementation of "determining the operation permission of the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request."

[0228] In this manner, the file permission corresponding to the target file user identifier is used as the operation permission corresponding to the operation request, thereby achieving the goal of determining the permission verification result using only the file permission, which helps to improve verification efficiency.

[0229] Method 2: The object storage service node determines the operation permission corresponding to the operation request based on the file ACL corresponding to the target identifier and the target file user identifier included in the operation request, as well as the object ACL corresponding to the target identifier and the object user identifier associated with the operation request.

[0230] In the embodiment of the present application, when the operation request includes a target file user identifier, the object user identifier corresponding to the target file user identifier is the object user identifier associated with the operation request. How to determine the object user identifier corresponding to the target file user identifier will be described in subsequent embodiments and will not be described in detail here. For details, see S203b.

[0231] In an embodiment of the present application, the target object stored in the object storage service node is configured with an object ACL, wherein the object ACL of the target object can be stored in the object storage service node.

[0232] It should be noted that regarding how to configure an object ACL for a target object, reference may be made to solutions in related technologies, and the embodiments of the present application do not impose any limitation on this.

[0233] In addition, since the identifier of the target object is the target identifier, the object ACL of the target object may also be referred to as the object ACL corresponding to the target identifier, or simply referred to as the object ACL of the target identifier.

[0234] In the embodiment of the present application, the object ACL refers to an ACL that uses object semantics to represent users and permissions, wherein the object ACL includes at least one object user identifier and at least one object permission corresponding to the object user identifier.

[0235] It should be noted that in the embodiment of the present application, there is no limit on the number of object user identifiers included in the object ACL. In addition, the object permission corresponding to at least one object user identifier can also be referred to as the object permission of at least one object user identifier.

[0236] The object user ID is the user ID in the object semantics, or in other words, the user ID that complies with the object semantics. The object permission is the permission in the object semantics, or in other words, the permission that complies with the object semantics.

[0237] In the embodiment of the present application, the object user identifier may include the ID of the object user, such as: abc1, ..., abc5, etc.

[0238] The following is an illustrative description of method 2 through steps 203a to 203d.

[0239] Step 203a: Based on the file ACL of the target object, determine the file permission corresponding to the target file user identifier.

[0240] It should be noted that for the relevant description of step 203a, reference can be made to the description in the above-mentioned method 1, which will not be repeated here.

[0241] Step 203b: Based on the user mapping relationship, determine the object user identifier corresponding to the target file user identifier as the target object user identifier.

[0242] The object user identifier corresponding to the target file user identifier is the object user identifier associated with the operation request, that is, the target object user identifier is the object user identifier associated with the operation request.

[0243] In an embodiment of the present application, an object storage service node stores a user mapping relationship, which includes a correspondence between at least one object user identifier and at least one file user identifier. Upon receiving an operation request, the object storage service node can determine the object user identifier corresponding to the target file user identifier in the operation request based on the user mapping relationship, thereby obtaining the object user identifier associated with the operation request.

[0244] It should be noted that in the embodiments of the present application, there is no restriction on the time for determining the object user identifier corresponding to the target file user; the above description is merely an example. For example, when reading the object ACL of the target object, the object storage service node may also determine, based on the user mapping relationship, whether the object user identifier read is the object user identifier associated with the operation request, that is, whether the object user identifier has a corresponding relationship with the target file user identifier.

[0245] Exemplarily, the target file user identifier is 6668, and the user mapping relationship includes a correspondence between abc1 and 6668. Based on this, the object storage service node determines abc1 as the target object user identifier.

[0246] Optionally, the permission verification method further includes: if the target file user identifier is not included in the user mapping relationship, the object storage service node sends a first response message, and the first response message is used to indicate no permission.

[0247] The user mapping relationship does not include the target file user identifier, which can be considered to mean that the user mapping relationship does not include the object user identifier corresponding to the target file user identifier.

[0248] In this embodiment, when the target file user identifier does not exist in the user mapping relationship, the object storage service node sends a first response message to the first client to notify the user that the user does not have permission. This helps the user adjust the access policy in a timely manner.

[0249] Step 203c: Based on the object ACL of the target object, determine the object permission corresponding to the target object user identifier.

[0250] In an embodiment of the present application, after determining the object user identifier associated with the operation request (ie, the target object user identifier), the object storage service node determines the object permission corresponding to the target object user identifier based on the object ACL of the target object.

[0251] For example, the target object user ID is abc1, and the target object ACL includes <id> abc1 < / id> as well as <id> abc1 < / id> Corresponding <permission> READ < / permission> Based on this, the object storage service node determines that the object permission corresponding to the target file object identifier is READ.

[0252] Step 203d: Determine the minimum permission among the file permission corresponding to the target file user identifier and the object permission corresponding to the target object user identifier as the operation permission corresponding to the operation request.

[0253] For example, combined with method 1, it can be seen that the file permission corresponding to the target file user identifier is "w". If the object permission corresponding to the target object user identifier is "READ", since the read permission represented by "READ" is less than the write permission represented by "w", the operation permission corresponding to the operation request is "READ", which means that the target file user only has read permission on the target node.

[0254] It should be noted that method 2 can be considered as another specific implementation method of "determining the operation permission of the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request."

[0255] In this method, the minimum permission among the file permissions corresponding to the target file user identifier and the object permissions corresponding to the target object is used as the operation permission corresponding to the operation request, so as to determine the permission verification result based on the minimum permission among the file permissions and object permissions, and then provide the user with dual permission verification. This helps to improve the standard of permission verification, and further helps to further improve the reliability and security of the file services provided by the object storage service node.

[0256] Step 204: The object storage service node determines a permission verification result based on the operation permission corresponding to the operation request and the target operation type, wherein the permission verification result includes verification success or verification failure.

[0257] In the above-described embodiment, the object storage service node provides users with a file permission verification service, that is, a permission verification service that complies with file semantics. When a user sends an operation request to the object storage service node through a first client, the object storage service node, after receiving the operation request, determines the operation permission corresponding to the operation request based on the target identifier indicated in the operation request, the file ACL of the target object, and the target file user identifier included in the operation request. The node then determines a permission verification result based on the relationship between the operation permission corresponding to the operation request and the target operation.

[0258] Since file ACLs that conform to file semantics are used to verify the permissions of target operations requested by users, fine-grained permission verification that conforms to file semantics is implemented for target operations requested by users. This not only helps to improve the accuracy of permission verification when users access file nodes or directory nodes, thereby helping to improve the security and reliability of file services provided by object storage systems, but also helps to diversify the permission verification methods when users access objects, thereby helping to improve the user experience.

[0259] Optionally, if the operation permission corresponding to the operation request includes the target operation type, it is determined that the permission verification result is successful.

[0260] Exemplarily, the operation permission corresponding to the operation request includes rx, and the target operation is a read operation (ie, r). Since rx includes r, the permission verification result is verification success.

[0261] Optionally, if the operation permission corresponding to the operation request does not include the target operation type, it is determined that the permission verification result is a verification failure.

[0262] Exemplarily, the operation permission corresponding to the operation request includes rx, and the target operation is a write operation (ie, w). Since rx does not include w, the permission check result is a check failure.

[0263] Optionally, step 205: the object storage service node responds to the operation request based on the permission verification result.

[0264] In one example, the permission verification result is successful, that is, the target file user has the permission to perform the target operation on the target node.

[0265] Based on this, responding to the operation request may include: performing the target operation on the target node according to the operation request. Executing the target operation on the target node according to the operation request may also be considered as processing the operation request.

[0266] Alternatively, responding to the operation request may include: performing a target operation on the target node according to the operation request, and sending fifth response information to the first client.

[0267] The fifth response information is used to indicate that the permission check is successful or that the user has permission. Exemplarily, the fifth response information may include a status code (Status-Code), and the status code may be 200, which indicates that the permission check is successful or that the user has permission.

[0268] In this embodiment, when the permission verification result is successful, the object storage service node sends a fifth response message to the first client, which helps the user to understand the permission verification result in a timely manner, thereby helping to improve the user's usage experience.

[0269] In another example, the permission check result is a verification failure, that is, the target file user does not have the permission to perform the target operation on the target node.

[0270] Based on this, responding to the operation request may include: sending a sixth response message to the first client, the sixth response message being used to indicate no permission or permission verification failure. Exemplarily, the sixth response message may include a status code (Status-Code), which may be 403, indicating permission verification failure or no permission.

[0271] In this embodiment, when the permission check result is a verification failure, the object storage service node sends a response message to the first client, which helps the user to understand the permission check result in a timely manner, thereby helping to improve the user's usage experience.

[0272] The permission verification method described in the above embodiment is a scheme for performing permission verification on the target file user who sends an operation request to the object storage service node through a first client. Different from the above scheme, the embodiment of the present application also provides another permission verification method, which is a scheme for performing permission verification on the target object user who sends an operation request to the object storage service node through a second client.

[0273] 3 , the differences between the two solutions are described in detail, and the similarities are not described in detail.

[0274] FIG3 is a flow chart of another permission verification method according to an exemplary embodiment. Exemplarily, the permission verification method may include the following steps 301 to 305 .

[0275] Optionally, a second client is installed on the electronic device. When the second client sends an operation request to the object storage service node, the user identifier carried in the operation request is the object user identifier.

[0276] It should be noted that in order to facilitate the distinction between users who use different clients to send operation requests to the object storage service node, the user who uses the second client can be called an object user, which will not be repeated later.

[0277] It should be noted that the second client can be an object storage client, or it can be other clients that carry an object user identifier when communicating with the object storage service node. This embodiment of the present application does not limit this.

[0278] It should be noted that the second client in the embodiment of the present application performs a certain operation, such as sending an operation request to the object storage service node, which can be considered as the electronic device performing a certain operation through the second client, or the electronic device performing a certain operation during the process of running the second client.

[0279] Step 301: The second client sends an operation request to the object storage service node.

[0280] In one example, a user logs in to a second client through an electronic device and performs a target operation on a target node / target object through the second client, such as a read operation, a write operation, a delete operation, etc. The second client sends an operation request to the object storage service node in response to the target operation performed by the user on the target node / target object.

[0281] In another example, when an electronic device needs to perform a target operation on a target node / target object during the process of running a file application / object application, the file application / object application sends a request to a second client, and the second client responds to the received request and sends an operation request to the object storage service node.

[0282] In an embodiment of the present application, the operation request may include a target object user identifier. The target object user identifier is the identifier of the target object user who sends the operation request to the object storage service node via the second client. In other words, the target object user is the target user requesting the target operation to be performed on the target node.

[0283] For example, a user enters an object account name and password on a login interface of a second client displayed on an electronic device. After logging into the second client, the second client sends an operation request to the object storage service node via an object interface (e.g., a REST API), including the target object user identifier corresponding to the object account name. The electronic device may store a correspondence between the object account name and the target object user identifier.

[0284] It should be noted that for other relevant descriptions of step 301, reference can be made to the above-mentioned step 201, which will not be repeated here.

[0285] Step 302: The object storage service node receives an operation request sent by the second client.

[0286] Exemplarily, the object storage service node may receive an operation request sent by the second client based on the object interface.

[0287] For example, if the operation request is a write request, the object interface can be PUT / filesystem / dir / file. If the operation request is a read request, the object interface can be GET / filesystem / dir / file. If the operation request is a delete request, the object interface can be DELETE / filesystem / dir / file.

[0288] It should be noted that step 302 can be considered as another implementation method of "the object storage service node receiving the operation request".

[0289] Step 303: The object storage service node determines the operation permission corresponding to the operation request.

[0290] There are multiple implementation methods for step 303 , and the following uses Method A and Method B for exemplary description.

[0291] In method A, the object storage service node determines the operation permission corresponding to the operation request based on the file ACL corresponding to the target identifier and the file user ID associated with the operation request.

[0292] In the embodiment of the present application, when the operation request includes a target object user identifier, the file user identifier corresponding to the target object user identifier is the file user identifier associated with the operation request.

[0293] The following is an exemplary introduction to the process of determining the object user identifier included in the operation request.

[0294] In one example, an object storage service node uses token authentication when communicating with a second client. The object storage service node stores a correspondence between tokens and object user identifiers. The second client sends an operation request to the object storage service node that carries a target token. Upon receiving the operation request, the object storage service node determines the object user identifier included in the operation request, i.e., the target object user identifier corresponding to the target token, based on the target token and the stored correspondence.

[0295] In another example, an object storage service node uses Ak / Sk authentication when communicating with a second client. The object storage service node stores a correspondence between the AK and the object user identifier. The second client sends an operation request to the object storage service node that carries a target access key identifier (AK). Upon receiving the operation request, the object storage service node determines the object user identifier included in the operation request, i.e., the target object user identifier corresponding to the target AK, based on the target AK and the stored correspondence.

[0296] The following is an illustrative description of method A through steps 303a to 303c.

[0297] Step 303a: Based on the user mapping relationship, determine the file user identifier corresponding to the target object user identifier as the target file user identifier.

[0298] The file user identifier corresponding to the target object user identifier is the file user identifier associated with the operation request, that is, the target object user identifier is the object user identifier associated with the operation request.

[0299] In an embodiment of the present application, an object storage service node stores a user mapping relationship, which includes a correspondence between at least one object user identifier and at least one file user identifier. Upon receiving an operation request, the object storage node determines, based on the user mapping relationship, the file user identifier corresponding to the target object user in the operation request, thereby obtaining the file user identifier associated with the operation request.

[0300] For example, the target object user identifier is abc1, and the user mapping relationship includes a correspondence between abc1 and 6668. Based on this, the object storage service node determines 6668 as the target file user identifier.

[0301] Optionally, the permission verification method further includes: if the user mapping relationship does not include a file user identifier corresponding to the target object user identifier, the object storage service node sends a second response message, and the second response message is used to indicate no permission.

[0302] In this embodiment, when the file user ID corresponding to the target object user ID does not exist in the user mapping relationship, a response message is sent to the object storage client to notify the user that the user does not have access rights so that the user can adjust the access policy in time.

[0303] It should be noted that for other related descriptions of step 303a, reference can be made to the above-mentioned step 203b, which will not be repeated here.

[0304] Step 303b: Based on the file ACL of the target object, determine the file permission corresponding to the target file user identifier.

[0305] Step 303c: Determine the file permission corresponding to the target file user identifier as the operation permission corresponding to the operation request.

[0306] It should be noted that for the relevant description of steps 303b to 303c, reference can be made to method 1 in the above step 203, which will not be repeated here.

[0307] It should be noted that method A can be considered as another specific implementation method of "determining the operation permission of the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request."

[0308] In this manner, the file permission corresponding to the file user identifier associated with the operation request is used as the operation permission corresponding to the operation request, thereby achieving the goal of determining the permission verification result using only the file permission, which helps to improve verification efficiency.

[0309] In method B, the object storage service node determines the operation permission corresponding to the operation request based on the file ACL corresponding to the target identifier and the file user identifier associated with the operation request, as well as the object ACL corresponding to the target identifier and the target object user identifier included in the operation request.

[0310] The following is an illustrative description of method B through steps 303d to 303g.

[0311] Step 303d: Based on the user mapping relationship, determine the file user identifier corresponding to the target object user identifier as the target file user identifier.

[0312] It should be noted that for the relevant description of step 303d, reference can be made to the above step 303a, which will not be repeated here.

[0313] Step 303e: Based on the file ACL of the target object, determine the file permission corresponding to the target file user ID.

[0314] It should be noted that the description of step 303e can refer to the description of method 1 in the above step 203, and will not be repeated here.

[0315] Step 303f: Based on the object ACL of the target object, determine the object permission corresponding to the target object user identifier.

[0316] It should be noted that the description of step 303f can refer to the description of step 203c above, which will not be repeated here.

[0317] Step 303g: Determine the minimum permission among the file permission corresponding to the target file user identifier and the object permission corresponding to the target object user identifier as the operation permission corresponding to the operation request.

[0318] It should be noted that the description of step 303g can refer to the description of step 203d above, which will not be repeated here.

[0319] It should be noted that method B can be considered as another specific implementation method of "determining the operation permission of the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request."

[0320] In this method, the minimum permission among the file permissions corresponding to the target file user identifier and the object permissions corresponding to the target object user identifier is used as the permission corresponding to the operation request, thereby determining the permission verification result based on the minimum permission among the file permissions and object permissions. This helps to improve the standard of permission verification, and further helps to improve the reliability and security of the file services provided by the object storage service node.

[0321] Step 304: The object storage service node determines a permission verification result based on the operation permission corresponding to the operation request and the target operation type.

[0322] It should be noted that for the relevant description of step 304, reference can be made to the above-mentioned step 204, which will not be repeated here.

[0323] In the above-described embodiment, the object storage service node provides users with a file permission verification service, that is, a permission verification service that complies with file semantics. When a user sends an operation request to the object storage service node via a second client request, the object storage service node, upon receiving the operation request, determines the operation permission corresponding to the operation request based on the target identifier indicated in the operation request, the file ACL of the target object, and the file user identifier associated with the operation request. Furthermore, the permission verification result is determined based on the relationship between the operation permission corresponding to the operation request and the target operation type.

[0324] Since file ACLs that conform to file semantics are used to verify the permissions of target operations requested by users, fine-grained permission verification that conforms to file semantics is implemented for target operations requested by users. This not only helps to improve the accuracy of permission verification when users access file nodes or directory nodes, thereby helping to improve the security and reliability of file services provided by object storage systems, but also helps to diversify the permission verification methods when users access objects, thereby helping to improve the user experience.

[0325] Optionally, step 305: the object storage service node responds to the operation request based on the permission verification result.

[0326] It should be noted that for the relevant description of step 305, reference can be made to the above-mentioned step 205, which will not be repeated here.

[0327] In the embodiment of the present application, the operation request may be a read request. The permission verification process of the read request is exemplarily described below with reference to FIG4 .

[0328] As shown in FIG4 , it is a schematic diagram of permission verification for a read request provided in an embodiment of the present application.

[0329] The user / file application / object application sends a read request to the object storage service node through the second client, such as: the read request can be "GET / filesystem / dir / file", and the read request carries token / AK. After receiving the read request, the object storage service node parses the read request and obtains the object user identifier corresponding to the token / AK in the read request, thereby determining the object user identifier included in the read request. Afterwards, the object storage service node searches for the file user identifier corresponding to the object user identifier through the user management module, thereby determining the file user identifier associated with the read request. If the corresponding file user identifier is not found, the object storage service node returns no permission to the second client (e.g., it can return operation code 403). If the corresponding file user identifier is found, the object storage service node reads the file ACL of the target identifier according to the target identifier indicated in the read request, and performs permission verification (i.e., authentication) through the permission module. If the authentication fails (i.e., the permission verification fails), the object storage service node returns no permission to the second client. If the authentication passes (i.e., the permission check succeeds), the object storage service node returns a request success to the second client (e.g., it can return operation code 200) and performs a read operation, that is, obtains the target element indicated by the target identifier (i.e., the target node / target object) and returns the target element to the second client.

[0330] In the embodiment of the present application, the operation request may be a write request. The permission verification process of the write request is exemplarily described below with reference to FIG5 .

[0331] As shown in FIG5 , it is a schematic diagram of permission verification for a write request provided in an embodiment of the present application.

[0332] The user / file application / object application sends a write request to the object storage service node through the second client, such as: the write request can be "PUT / filesystem / dir / file", and the write request carries token / AK. After receiving the write request, the object storage service node parses the write request and obtains the object user identifier corresponding to the token / AK in the write request, thereby determining the object user identifier included in the write request. Afterwards, the object storage service node searches for the file user identifier corresponding to the object user identifier through the user management module, thereby determining the file user identifier associated with the write request. If the corresponding file user identifier is not found, the object storage service node returns no permission to the second client (such as: it can return operation code 403). If the corresponding file user identifier is found, the object storage service node reads the file ACL of the target identifier according to the target identifier indicated by the write request, and performs authentication (i.e., permission check) through the permission module. If the authentication fails (i.e., the permission check fails), the object storage service node returns no permission to the second client. If the authentication passes (i.e., the permission check succeeds), the object storage service node returns a successful request to the second client (e.g., it can return operation code 200) and performs a write operation, that is, performs a write operation on the target element indicated by the target identifier (i.e., the target node / target object).

[0333] In the embodiment of the present application, the operation request may be a deletion request. The permission verification process of the deletion request is exemplarily described below with reference to FIG6 .

[0334] As shown in FIG6 , it is a schematic diagram of permission verification for a deletion request provided in an embodiment of the present application.

[0335] The user / file application / object application sends a deletion request to the object storage service node through the second client. For example, the deletion request can be "DELETE / filesystem / dir / file", and the deletion request carries token / AK. After receiving the deletion request, the object storage service node parses the deletion request and obtains the object user identifier corresponding to the token / AK in the deletion request, thereby determining the object user identifier included in the deletion request. Afterwards, the object storage service node searches for the file user identifier corresponding to the object user identifier through the user management module, thereby determining the file user identifier associated with the deletion request. If the corresponding file user identifier is not found, the object storage service node returns "no permission" to the second client (for example, it can return operation code 403). If the corresponding file user identifier is found, the object storage service node reads the file ACL of the target identifier based on the target identifier indicated in the deletion request and performs authentication (i.e., permission check) through the permission module. If the authentication fails (i.e., the permission check fails), the object storage service node returns "no permission" to the second client. If the authentication passes (i.e., the permission check succeeds), the object storage service node returns a successful request to the second client (e.g., it can return operation code 200) and performs a deletion operation, that is, deleting the target element indicated by the target identifier (i.e., the target node / target object).

[0336] The above embodiment describes a scheme for performing permission verification on an object storage service node. The present application also provides another scheme for configuring ACLs for objects stored on the object storage service node, also known as a permission setting scheme. The following, in conjunction with Figure 7, details the differences between the two schemes, and will not further elaborate on the similarities.

[0337] Fig. 7 is a flow chart showing a method for setting permissions according to an exemplary embodiment. Exemplarily, the method for setting permissions includes the following steps 701 to 706.

[0338] Optionally, a third client is installed on the electronic device, and the third client can be used to send a file permission setting request to the object storage service node to request to configure the object configuration file ACL stored for the object storage service node.

[0339] Exemplarily, the third client may be a console client, or may be other clients capable of configuring object profile ACLs stored for object storage service nodes, which is not limited in this embodiment of the present application.

[0340] It should be noted that the third client in the following embodiments performs a certain operation, such as sending a file permission setting request to the object storage service node. It can be considered that the electronic device performs a certain operation through the third client, or the electronic device performs a certain action during the process of running the third client, which will not be repeated later.

[0341] It should be noted that the electronic device running the third client and the electronic device running the first client / second client may be the same electronic device, or may be different electronic devices, and this embodiment of the present application does not impose any limitation on this.

[0342] In addition, the third client and the first client / the second client may also be clients of the same type, or clients of different types, which is not limited in this application.

[0343] The following describes the permission setting method provided in the embodiment of the present application by taking the target object stored in the object storage service node as an example.

[0344] Step 701: The third client obtains the file ACL corresponding to the target identifier.

[0345] In an embodiment of the present application, when a user needs to set file permissions for a target object / target node, such as setting ACL permissions, the user can add file permissions to the target object's access control policy based on the target identifier (i.e., the identifier of the target object / target node). In other words, permissions that conform to file semantics can be set for the target object's access control policy. In this way, when a user requests to perform a target operation on a target object / target node, the object storage service node can perform permission verification that conforms to file semantics based on the target object's access control policy.

[0346] In the embodiment of the present application, step 701 may include multiple implementation methods, and the following is exemplified by methods 1 to 3.

[0347] Method 1: The third client obtains the file ACL corresponding to the target identifier based on the second control on the second interface.

[0348] The second control is used to indicate the file ACL.

[0349] For example, as shown in (a) of FIG8A , after a user logs in to a third client using an electronic device, the third client displays a first interface via the electronic device. The first interface includes a first control, and the first control is used to indicate a target object / target node. As shown in (b) of FIG8A , the user performs a trigger operation on the first control, such as selecting the first control and right-clicking the mouse. The third client displays an options page for the first control via the electronic device, and then selects the "Set ACL" option on the options page.

[0350] As shown in (c) of FIG8A , in response to a user triggering an operation on the first control, the third client displays a second interface on the electronic device. The second interface includes a second control for indicating a file ACL. The user performs an input operation on the second control, such as inputting a file ACL on the second control. As shown in (d) of FIG8A , the third client obtains the file ACL in response to the user input operation on the second control and displays the file ACL on the second control on the electronic device.

[0351] In this manner, the third client provides the user with an interface for editing the file ACL, so that the user can edit the file ACL on the second control, thereby visualizing the setting process and helping to improve operational convenience and user experience.

[0352] Optionally, the second control is used to indicate an access control policy, where the access control policy includes an object ACL and a file ACL.

[0353] In this embodiment, by adding a file ACL to the access control policy of the target object, the operation process of setting the object ACL is expanded to also allow the file ACL to be set at the same time. That is, the operation process of setting the object ACL is the same as the operation process of setting the file ACL, so that the user does not need to learn a new operation process, which helps to improve the user experience.

[0354] Method 2: The third client obtains the file ACL corresponding to the target identifier based on the fifth control on the fifth interface.

[0355] The fifth control is used to indicate the storage address of the permission file, and the permission file includes the file ACL.

[0356] For example, as shown in (a) of FIG8B , after a user logs in to a third client using an electronic device, the third client displays a first interface via the electronic device. The first interface includes a first control, and the first control is used to indicate a target object / target node. As shown in (b) of FIG8B , the user performs a trigger operation on the first control, such as selecting the first control and right-clicking the mouse. The third client displays an options page for the first control via the electronic device, and then selects the "Set ACL" option on the options page.

[0357] As shown in (c) of FIG8B , the third client displays a fifth interface through the electronic device in response to a trigger operation on the first control, and the fifth interface includes a fifth control and an import control. The user performs a trigger operation on the import control, such as: the user clicks the import control, and the third client displays the directory where the permission file is located through the electronic device. The user selects the permission file, as shown in (d) of FIG8B . The third client obtains the storage address of the permission file in response to the user's trigger operation on the import control and displays the storage address of the permission file on the fifth control. The third client can obtain the permission file based on the storage address, thereby achieving the file ACL of the target identifier.

[0358] In this method, a file ACL import interface is provided to the user through a third client, allowing the user to import a pre-edited file ACL into the third client as the file ACL corresponding to the target identifier. In this way, one file ACL can be used for multiple different objects / nodes, which helps to avoid users from repeatedly editing file ACLs, thereby helping to improve the user experience and the efficiency of setting file permissions for target objects.

[0359] Method 3: The third client obtains the file ACL corresponding to the target identifier based on the target application.

[0360] The target application code includes file ACL.

[0361] Exemplarily, the third client calls the target application to obtain the file ACL from the code of the target application.

[0362] In this approach, by presetting the file ACL in the code of the target application, the file ACL corresponding to the target identifier can be automatically obtained by running the target application, which helps to improve the convenience of obtaining the file ACL.

[0363] In addition, when users need to set file permissions for multiple nodes / objects, the target application code can include the file ACLs of multiple nodes / objects, so that the file ACLs of multiple nodes / objects can be obtained at one time through the target application, which helps to improve the convenience and efficiency of permission setting operations, and thus helps to improve the user experience.

[0364] It should be noted that the method of obtaining the file ACL in the embodiment of the present application is not limited, and the above is only an exemplary description.

[0365] Step 702: The third client sends a file permission setting request to the object storage service node.

[0366] The file permission setting request is used to request setting of ACL permission, and the permission setting request includes a target identifier and a file ACL corresponding to the target identifier.

[0367] Optionally, step 702 may include: the third client sends a file permission setting request to the object storage service node through the object ACL setting interface.

[0368] The object ACL setting interface is an interface provided by the object storage service node for setting the object ACL for an object.

[0369] Based on Method 1 in step 701 above, the "Set ACL" option in the first control's options page is associated with the object ACL setting interface. The object ACL setting interface can be used to set both file ACLs and object ACLs. In this case, setting file ACLs and object ACLs can use the same interface, namely, the object ACL setting interface.

[0370] For example, the object ACL setting interface can be a REST API interface, and can be PUT / ObjectName? acl. "PUT" represents setting (or updating), "ObjectName" represents the target identifier, and "acl" represents the ACL. For example, ObjectName can be filesystem / dir / file, meaning the target identifier can be filesystem / dir / file.

[0371] In this embodiment, the semantics of adding file ACLs to the object's access control policy are implemented by extending the object's REST API interface. Due to the good scalability of the HTTP protocol, setting file ACLs by extending the REST API interface is not only simple to implement but also low-cost.

[0372] In an embodiment of the present application, after the third client obtains the file ACL corresponding to the target identifier, it calls the object ACL setting interface provided by the object storage service node and sends a file permission setting request to the object storage service node.

[0373] In one example, the second interface may also include a send control. After the user enters the file ACL on the second control, he clicks the send control. In response to the user's triggering operation on the send control, the third client calls the object ACL setting interface and sends a file permission setting request to the object storage service node.

[0374] Exemplarily, after the user selects the "Set ACL" option, the object ACL setting interface may be automatically displayed on the second control, that is, the second control may also be used to indicate the object ACL setting interface.

[0375] In another example, the permission file may include an object ACL setting interface, and the fifth interface may also include a send control. After the storage address of the permission file is displayed on the fifth control, the user clicks the send control. The third client responds to the user's triggering operation on the send control, calls the object ACL setting interface in the permission file, and sends a file permission setting request to the object storage service node.

[0376] In another example, the code of the target application may further include an object ACL setting interface. The third client may call the object ACL setting interface in the code of the target application to send a file permission setting request to the object storage service node.

[0377] This embodiment uses the object ACL configuration interface provided by the object storage service node to set file ACLs. This fully utilizes the existing interface of the object storage service node, eliminating the need for cloud service providers to develop new interfaces specifically for setting file ACLs for the object storage service node, thus helping to reduce cloud service costs. Furthermore, cloud service users do not need to learn and master new interfaces, which reduces the difficulty of setting file ACLs and, in turn, improves the user experience.

[0378] In the embodiment of the present application, the third client may also set the file ACL through other interfaces provided by the object storage service node in addition to the object ACL setting interface, such as the file ACL setting interface.

[0379] In this method, the object storage service node provides users with a separate interface for setting file permissions. In this way, after the client obtains the file ACL, it can call the file ACL setting interface and send a file permission setting request to the object storage service node, thereby setting object ACL and file ACL through different interfaces, which helps to ensure the independence of interfaces with different functions.

[0380] It should be noted that there is no limitation on the interface used by the third client in the embodiment of the present application to send a file permission setting request to the object storage service node, and the above is only an exemplary description.

[0381] Step 703: The object storage service node receives a file permission setting request sent by the third client.

[0382] The permission setting request includes a target identifier and a file ACL corresponding to the target identifier.

[0383] In one example, the object storage service node may receive a file permission setting request sent by a third client based on an object ACL setting interface. In another example, the object storage service node may receive a file permission setting request sent by a third client based on a file ACL setting interface.

[0384] Step 704: The object storage service node stores the file ACL corresponding to the target identifier in the object storage service node according to the target identifier.

[0385] In an embodiment of the present application, after the object storage service node receives a file permission setting request, it stores the file ACL in the file permission setting request in the object storage service node based on the target identifier in the file permission setting request, thereby configuring the file ACL for the target object stored in the object storage service node.

[0386] In one example, the object storage service node can store the file ACL in a file permission setting request in the metadata of the target object indicated by the target identifier. This helps improve the accuracy of the file ACL corresponding to the target identifier when performing permission verification on operation requests containing the target identifier.

[0387] In another example, the object storage service node can store the file ACL in the file permission setting request in a separate storage device. In this way, the file ACLs of multiple objects stored on the object storage service node can be centrally stored, thereby helping to improve the convenience of file ACL storage.

[0388] It should be noted that, below, the embodiment of the present application is exemplarily described by taking the case where the file ACL is stored in the metadata of the target object as an example.

[0389] In the embodiment of the present application, the file ACL may include one or more ACEs, wherein an ACE includes a file user identifier and a file permission corresponding to the file user identifier.

[0390] On this basis, step 704 may include: the object storage service node stores each ACE of the file ACL in the metadata of the target object based on the target identifier.

[0391] In an embodiment of the present application, after receiving a file permission setting request, the object storage service node may parse each ACE in the file ACL and store each ACE in the metadata of the target object.

[0392] For example, the file ACL is stored in the form of an XML Body. The object storage service node parses each ACE of the file ACL from the XML Body and stores it in the metadata of the target object.

[0393] In this embodiment, an object storage service node is set to store each ACE of the file ACL separately. In this way, when the file ACL is subsequently updated, such as adding, deleting, overwriting, changing, etc., the update can be performed on a single ACE. Compared with updating the entire file ACL, this helps to improve the update accuracy of the file ACL, and further helps to improve the update convenience and efficiency.

[0394] There are multiple implementation methods for storing file ACLs, which are exemplified below using methods a and b.

[0395] Method a: The object storage service node writes the file ACL into the access control policy of the target object.

[0396] The metadata of the target object includes an access control policy, and the access control policy includes an object ACL of the target object.

[0397] Exemplarily, before setting the file ACL for the target object, the user has already set the object ACL for the target object, that is, the access control policy of the target object includes the object ACL of the target object.

[0398] Optionally, when the third client sends a file permission setting request to the object service node through the object ACL setting interface, the object service node writes the file ACL in the operation request into the access control policy of the target object, that is, stores the object ACL and file ACL of the target object in the same Xml Body.

[0399] In this method, by writing the file ACL into the access control policy of the target object, the file ACL and object ACL of the target object are stored in one file. In this way, when verifying the file permissions and object permissions of the target node / target object at the same time, the object storage service node only needs to read one file (such as the XML Body) to obtain the file ACL and object ACL at the same time, which helps to improve the efficiency of permission verification.

[0400] Optionally, the object storage service node can write each ACE in the file ACL to the target object's access control policy. This helps improve the accuracy of file ACL updates, thereby improving the convenience and efficiency of updates.

[0401] Method b: The object storage service node stores the file ACL in the metadata of the target object.

[0402] Exemplarily, after receiving a file permission setting request, the object storage service node can store the file ACL in the file permission setting request separately in the metadata of the target object, that is, store it in two different files (such as Xml Body) with the object ACL of the target object.

[0403] In this way, each ACE of the file ACL in the file permission setting request can be written into the metadata of the target object. This helps to improve the update accuracy of the file ACL, and further helps to improve the convenience and efficiency of the update.

[0404] Exemplarily, when the third client sends a file permission setting request to the object service node through an interface other than the object ACL setting interface, such as the file ACL setting interface, the object service node writes the file ACL in the file permission setting request into the metadata of the target object, that is, stores the object ACL and file ACL of the target object in two different Xml Bodies respectively.

[0405] In this method, by storing the file ACL as a separate ACL file in the metadata of the target object, it helps to avoid confusion between the file ACL and the object ACL of the target object or misplacement during storage, thereby helping to ensure the accuracy of the file ACL and, in turn, the accuracy of the ACL permission check performed on users accessing the target node.

[0406] In the above embodiment, after receiving a file permission setting request, the object storage service node stores the file ACL corresponding to the target identifier in the file permission setting request in the object storage service node, such as in the metadata of the target object, based on the target identifier included in the file permission setting request (i.e., the identifier of the target object / target node), thereby configuring the file ACL for the target object. Since the file ACL includes the file user identifier (such as uid, gid, etc.) and the file permissions (such as r, w, x, etc.), it is possible to add elements for representing the file user and elements for representing the file permissions to the access control policy of the target object, thereby making the access control policy of the target object more consistent with file semantics, and further enabling the object storage server node to provide fine-grained permission verification that conforms to file semantics.

[0407] Optionally, step 705: the object storage service node sends seventh response information to the third client.

[0408] The seventh response information is used to indicate the file permission setting result.

[0409] It should be noted that, for the relevant description of the seventh response information, reference can be made to the description of the fifth response information and the sixth response information in the above S205, which will not be repeated here.

[0410] In an embodiment of the present application, the object storage service node may send a seventh response message to the third client based on an interface for receiving a file permission setting request, such as an object ACL setting interface or a file ACL setting interface.

[0411] Optionally, step 706: the third client receives seventh response information sent by the object service node.

[0412] In the embodiment of the present application, after receiving the seventh response information, the third client may directly display the status code in the seventh response information, or may also display the status represented by the status code.

[0413] In the above embodiment, after the object storage service node stores the file ACL corresponding to the target identifier in the metadata of the target object, it notifies the user of the result of the file permission setting by sending the seventh response information to the third client. This helps the user to promptly understand whether the file permission setting request is successful, and then, if the permission setting request is not successfully set, it can be reset in time to avoid affecting subsequent permission verification.

[0414] In the embodiment of the present application, after setting the file ACL for the target object, the user can also update the file ACL of the target object. The following is an exemplary introduction to the process of the user updating the file ACL of the target object.

[0415] Figure 9 is a flow chart showing a method for updating file permissions according to an exemplary embodiment. Exemplarily, the method for updating file permissions includes the following steps 901 to 906.

[0416] Step 901: The third client obtains the updated file ACL corresponding to the target identifier.

[0417] It should be noted that for the relevant description of step 901, reference can be made to the above-mentioned step 701, which will not be repeated here.

[0418] Step 902: The third client sends a file permission update request to the object storage service node.

[0419] The file permission update request includes a target identifier and an updated file ACL corresponding to the target identifier.

[0420] Optionally, the file permission update request may further include a setting type for updating the file ACL.

[0421] The setting type for updating the file ACL may include at least one of an add type, a delete type, an override type, and a modify type. The setting type may be used to indicate the type of operation performed on updating the file ACL.

[0422] In this embodiment, by setting the setting type of the updated file in the file permission update request, it is helpful to provide users with a variety of different update methods through the file permission update request, such as: adding, deleting, overwriting, changing, etc., thereby improving the flexibility of file ACL updates and further improving the user experience.

[0423] In an embodiment of the present application, a file permission setting request may refer to a request sent when a file ACL is set for an object for the first time. A file permission update request refers to a request sent when a file ACL is not set for an object for the first time. Setting a file ACL for an object for a non-first time can be considered an update to the file ACL that was set for the object for the first time.

[0424] Optionally, the file permission setting request in step 702 may further include a file ACL setting type, where the file ACL setting type is a new type, which helps ensure format consistency when setting the file ACL and updating the historical file ACL.

[0425] In the embodiment of the present application, the setting type of the updated file ACL can be stored in the updated file ACL.

[0426] For example, when the setting type is add, updating the file ACL may include: <type> add < / type> When the setting type is delete, updating the file ACL can include <type> delete < / type> When the setting type is override, updating the file ACL can include <type> override < / type> When the setting type is change (modify), updating the file ACL can include <type> modify < / type> .

[0427] It should be noted that the way in which the third client sends a file permission update request to the object storage service node (such as the interface used, etc.) is the same as the way in which the third client sends a file permission setting request to the object storage service. Therefore, the relevant instructions for step 902 can refer to the above step 702 and will not be repeated here.

[0428] Step 903: The object storage service node receives a file permission update request sent by the third client.

[0429] It should be noted that for the relevant description of step 903, reference can be made to the above-mentioned step 703, which will not be repeated here.

[0430] Step 904: The object storage service node updates the file ACL corresponding to the target identifier.

[0431] In an embodiment of the present application, after the object storage service node receives a file permission update request, it updates the file ACL corresponding to the target identifier (i.e., the file ACL of the target object stored by the object storage service node) based on the target identifier, the updated file ACL, and the setting type of the updated file ACL.

[0432] Optionally, the file ACL includes one or more ACEs, and step 904 includes: the object storage service node updates the one or more ACEs in the file ACL corresponding to the target identifier.

[0433] In an embodiment of the present application, when updating the file ACL of a target object, one or more ACEs of the file ACL of the target object can be updated. Compared with updating the file ACL of the entire target object, this helps to improve the update accuracy of the file ACL, thereby helping to improve the update convenience and update efficiency.

[0434] The following describes step 904 by taking the example that the target object's file ACL includes ACE1, ACE2, and ACE3. ACE1 includes: <uid> 6668< / uid> and with <uid> 6668< / uid> Corresponding <permission> w< / permission> ACE2 includes: <gid> 6670< / gid> and with <gid> 6670< / gid> Corresponding <permission> rw< / permission> ACE3 includes: <uid> other < / uid> 、 <gid> other < / gid> and with <uid> other < / uid> 、 <gid> other < / gid> Corresponding <permission> r< / permission> .

[0435] It should be noted that, for the sake of distinction, the file ACL of the target object is referred to as the historical file ACL below.

[0436] In one example, updating a file ACL includes <uid> 6669< / uid> and with <uid> 6669< / uid> Corresponding <permission> rwx < / permission> , the setting type of updating file ACL is new. Based on this, the object storage service node will <uid> 6669< / uid> and with <uid> 6669< / uid> Corresponding <permission> rwx < / permission> Write the history file ACL, that is, add the updated file ACL to the history file ACL.

[0437] In another example, updating a file ACL includes <uid> 6668< / uid> and with <uid> 6668< / uid> Corresponding <permission> w< / permission>The setting type of the updated file ACL is deletion. Based on this, the object storage service node deletes ACE1 in the historical file ACL, that is, deletes the updated file ACL from the historical file ACL.

[0438] In yet another example, updating a file ACL includes <uid> 6669< / uid> and with <uid> 6669< / uid> Corresponding <permission> rwx < / permission> , update the file ACL setting type to overwrite, based on this, the object storage service node will " <uid> 6669< / uid> and with <uid> 6669< / uid> Corresponding <permission> rwx < / permission> "Overwrite ACE1, ACE2, and ACE3 in the history file ACL. That is, the updated file ACL will overwrite the history file ACL.

[0439] In yet another example, updating a file ACL includes <uid> 6668< / uid> and with <uid> 6668< / uid> Corresponding <permission> rwx < / permission> , the setting type of the updated file ACL is changed. Based on this, the object storage service node changes the file permission of ACE1 in the historical file ACL to " <permission> rwx< / permission> ”, that is, the first ACE in the history file ACL is changed to the second ACE in the update file ACL, wherein the first ACE and the second ACE have the same file user identifier.

[0440] Step 905: The object storage service node sends an eighth response message to the third client.

[0441] Step 906: The third client receives the eighth response information sent by the object storage service node.

[0442] It should be noted that for the relevant description of steps 905 and 906, reference can be made to the description of steps 705 and 706 above, which will not be repeated here.

[0443] In the above embodiment, the object storage service node provides users with the function of updating file ACL (such as adding, deleting, overwriting, and changing). When the file ACL needs to be updated, the user can send a file permission update request to the object storage service node through the client on the electronic device, and carry the object / node identifier, the updated file ACL, and the setting type of the updated file ACL in the file permission update request. In this way, after receiving the file permission update request, the object storage service node can update the historical file ACL of the object / node based on the object / node identifier, the updated file ACL, and the setting type of the updated file ACL, thereby improving the flexibility and convenience of the file ACL setting.

[0444] In the embodiment of the present application, after setting the file ACL for the target object, the user can also manage the file ACL of the target object. The following is an exemplary introduction to the process of the user managing the file ACL of the target object.

[0445] Optionally, the file ACL and object ACL of the target object can be managed synchronously, or the file ACL and object ACL of the target object can be managed separately, which is not limited in this embodiment of the present application. Below, taking only the file ACL of the target object as an example, the permission management method provided by the embodiment of the present application is exemplarily introduced.

[0446] FIG10 is a flow chart showing a method for rights management according to an exemplary embodiment. Exemplarily, the method for rights management includes the following steps 1001 to 1005 .

[0447] Step 1001: The third client sends a file permission management request to the object storage service node.

[0448] The file permission management request includes a target identifier, and the file permission management request is used to request management of a file ACL.

[0449] It should be noted that when file ACL and object ACL are managed synchronously, the permission management request is used to request management of the ACL of the target object. The ACL of the target object includes the file ACL and the object ACL.

[0450] Exemplarily, the object storage service node provides an object ACL management interface, which is an interface for managing object ACLs. The third client can send a file permission management request to the object storage service node based on the object ACL management interface.

[0451] It should be noted that for the description of the object ACL management interface, reference may be made to the description of the object ACL setting interface in step 702 above, which will not be repeated here.

[0452] In this example, the object ACL management interface provided by the object storage service node is used to manage file ACLs. This fully utilizes the existing interface provided by the object storage service node, eliminating the need for cloud service providers to develop new interfaces specifically for managing file ACLs, which helps reduce cloud service costs. Furthermore, cloud service users don't need to learn and master new interfaces, which reduces the difficulty of managing file ACLs and improves the user experience.

[0453] In the embodiment of the present application, the third client may also manage the file ACL through other interfaces provided by the object storage service node in addition to the object ACL management interface, such as the file ACL management interface.

[0454] In this example, the object storage service node provides users with an interface for managing file ACLs separately. In this way, a third-party client can send a file permission management request to the object storage service node by calling the file ACL management interface, thereby managing object ACLs and file ACLs through different interfaces, helping to ensure the independence of interfaces with different functions.

[0455] In the embodiment of the present application, the file permission management request includes multiple situations, which are explained below through situation 1 to situation 2.

[0456] Case 1: The file permission management request includes a file permission query request.

[0457] The file permission query request is used to request to query the file ACL.

[0458] For example, as shown in (a) of FIG11A , after a user logs in to a third client using an electronic device, the third client displays a first interface through the electronic device, and the first interface includes a first control. As shown in (b) of FIG11A , when the user needs to query the file ACL of a target object / target node, a second trigger operation can be performed on the first control, such as: the user selects the first control and clicks the right button of the mouse, and the third client displays the option page of the first control through the electronic device, and the user selects the "Query File ACL" option on the option page. In response to the user's second trigger operation on the first control, the third client sends a file permission query request to the object storage service node.

[0459] In this embodiment, by setting the file permission management request to include a file permission query request, the user can query the file ACL previously set for the target object, thereby helping the user to promptly understand the content of the file ACL of the target object.

[0460] Optionally, the object ACL management interface includes an object ACL query interface. Exemplarily, the object ACL query interface can be a REST API interface, such as GET / ObjectName? acl&type=fileonly. "GET" represents the query, "ObjectName?" represents the target identifier, and "acl&type=fileonly" represents the file ACL.

[0461] It should be noted that when file ACL and object ACL are managed synchronously, the object ACL query interface can be GET / ObjectName? acl. In addition, the "Query File ACL" shown in (b) of FIG11A can be "Query ACL".

[0462] It should be noted that the file ACL management interface may also include a file ACL query interface.

[0463] In one example, the third client may send a file permission query request to the object storage service node via the object ACL query interface. In another example, the third client may send a file permission query request to the object storage service node via the file ACL query interface.

[0464] Case 2: The file permission management request includes a file permission deletion request.

[0465] The file permission deletion request is used to request the deletion of a file ACL.

[0466] For example, as shown in (a) of FIG11B , after a user logs in to a third client using an electronic device, the third client displays a first interface through the electronic device. The first interface includes a first control, and the first control is used to indicate a target node / target object. As shown in (b) of FIG11B , when a user needs to delete a file ACL, a third trigger operation can be performed on the first control, such as selecting the first control and right-clicking the mouse. After the third client displays the option page of the first control through the electronic device, the third client selects the "Delete File ACL" option on the option page. In response to the user's third trigger operation on the second control, the third client sends a file permission deletion request to the object storage service node.

[0467] In this embodiment, by setting the file permission management request to include a file permission deletion request, when the user needs to cancel the file permission check for the target node / target object, the file ACL previously set for the target object can be deleted, which helps to improve the user experience.

[0468] Optionally, the object ACL management interface includes an object ACL deletion interface.

[0469] For example, the object ACL deletion interface type may be a REST API interface, and the object ACL deletion interface may be DELETE / ObjectName? acl&type=fileonly, where "DELETE" is used to indicate deletion, "ObjectName?" is used to indicate the target identifier, and "acl&type=fileonly" is used to indicate the file ACL.

[0470] It should be noted that when file ACL and object ACL are managed synchronously, the object ACL deletion interface can be DELETE / ObjectName? acl. In addition, the "delete file ACL" shown in (b) of FIG11B can be "delete ACL".

[0471] It should be noted that the file ACL management interface may also include a file ACL deletion interface.

[0472] In one example, the third client may send a file permission deletion request to the object storage service node via the object ACL deletion interface. In another example, the third client may send a file permission deletion request to the object storage service node via the file ACL deletion interface.

[0473] Step 1002: The object storage service node receives a file permission management request sent by a third client.

[0474] In one example, the object storage service node may receive a file permission management request based on an object ACL management interface. In another example, the object storage service node may receive a file permission management request based on a file ACL management interface.

[0475] Step 1003: The object storage service node manages the file ACL corresponding to the target identifier based on the target identifier.

[0476] In one example, corresponding to the above situation 1, the file permission management request includes a file permission query request.

[0477] Based on this, managing the file ACL of the target object includes: obtaining the file ACL from metadata of the target object.

[0478] Exemplarily, the object storage service node may further edit the file ACL into an XML Body format, so as to return the file ACL in the XML Body format to the third client.

[0479] It should be noted that when synchronously managing file ACLs and object ACLs, the object storage service node can obtain the file ACL and object ACL of the target object from the metadata of the target object.

[0480] In another example, corresponding to the above situation 2, the file permission management request includes a file permission deletion request.

[0481] Based on this, managing the file ACL of the target object includes: deleting the file ACL in the metadata of the target object.

[0482] It should be noted that when synchronously managing file ACLs and object ACLs, the object storage service node deletes the file ACLs and object ACLs in the metadata of the target object.

[0483] Step 1004: The object storage service node sends a ninth response message to the third client.

[0484] In one example, corresponding to Case 1 in the above step 1001 , when the file permission management request includes a file permission query request, the ninth response information may include: the file ACL of the target object.

[0485] In another example, corresponding to case 2 in step 1001 above, when the file permission management request includes a file permission deletion request, the ninth response information includes: the deletion result of the file ACL, and the deletion result includes deletion success or deletion failure.

[0486] Step 1005: The third client receives the ninth response information sent by the object storage service node.

[0487] In one example, corresponding to case 1 in the above step 1001, when the file permission management request includes a file permission query request, as shown in (c) in Figure 11A, after the user sends the file permission query request through the third client, the third client receives the ninth response information sent by the object storage service node, and then displays the management interface through the electronic device. The management interface includes an ACL control, and the ACL control is used to indicate the file ACL.

[0488] It should be noted that when the file ACL and the object ACL are synchronously managed, the third client displays the file ACL and the object ACL of the target object through the electronic device.

[0489] In another example, corresponding to case 2 in step 1001 above, when the file permission management request includes a file permission deletion request, based on this, as shown in (c) in FIG11B , after the user sends a permission deletion request through a third client, the third client receives the ninth response information sent by the object storage service node, and displays a management interface through an electronic device. The management interface includes a deletion control, and the deletion control is used to indicate the deletion result of the file ACL of the target object, such as: the deletion result is a successful deletion.

[0490] It should be noted that when file ACL and object ACL are managed synchronously, the delete control is used to indicate the deletion result of the file ACL and object ACL of the target object.

[0491] In the above embodiment, the object storage service node provides users with file ACL management (such as query, deletion, etc.) functions. When it is necessary to manage the file ACL of an object, the user can send a file permission management request to the object storage service node through a third client, such as a file permission query request, a file permission deletion request, etc., thereby managing the file ACL stored on the object storage service node, that is, managing the file ACL previously set for the object.

[0492] The above embodiment describes a solution for configuring and managing file ACLs for objects. On this basis, the embodiment of the present application also provides another solution for setting user mapping relationships for objects.

[0493] Fig. 12 is a flow chart showing a method for setting a user mapping relationship according to an exemplary embodiment. Exemplarily, the method for setting a user mapping relationship includes the following steps: Step 1201 to Step 1206.

[0494] Step 1201: The third client obtains a user mapping relationship.

[0495] The mapping relationship includes a corresponding relationship between at least one object user identifier and at least one file user identifier.

[0496] Optionally, one object user ID may correspond to one or more file user IDs.

[0497] That is, one object user ID may have a corresponding relationship with one file user ID, or one object user ID may have a corresponding relationship with multiple file user IDs.

[0498] In the embodiment of the present application, an object user identifier and one or more file user identifiers corresponding to the object user identifier can be referred to as a set of correspondences. For example, object user identifier 1 (e.g., abc1) corresponds to uid=6668, gid=6670; object user identifier 2 (e.g., abc2) corresponds to uid=6669, gid=6670; object user identifier 3 (e.g., abc3) corresponds to uid=667, gid=6672; object user identifier 4 (e.g., abc4) corresponds to uid=other, gid=other; and object user identifier 5 (e.g., abc5) corresponds to uid=6674.

[0499] It should be noted that the user mapping relationship may include one or more groups of corresponding relationships, and the embodiments of the present application do not limit this.

[0500] In the embodiment of the present application, step 1201 may include multiple implementation methods. The following is an illustrative description using Method 1 and Method 2.

[0501] Method 1: The third client obtains the user mapping relationship of the target bucket.

[0502] The target bucket stores the target object, and the user mapping relationship of the target bucket belongs to each object stored in the target bucket. In other words, the application scope of the user mapping relationship of the target bucket is each object in the target bucket.

[0503] In this method, the object storage service node provides users with the function of configuring user mapping relationships for buckets. In this way, when users need to configure user mapping relationships for each object in the bucket, they can configure user mapping relationships for each object in the bucket by configuring user mapping relationships for the bucket, which helps to improve the convenience of configuring user mapping relationships.

[0504] Optionally, there are multiple implementations for how to obtain the user mapping relationship, which are exemplified below using Method 1A and Method 1B.

[0505] Method 1A: Acquire a user mapping relationship based on at least one third control on the third interface and at least one fourth control corresponding to the at least one third control.

[0506] The third control is used to indicate the object user ID, and the fourth control is used to indicate the file user ID.

[0507] In the embodiment of the present application, a third control may correspond to one or more fourth controls, wherein a third control and one or more fourth controls corresponding to the third control are used to determine a set of corresponding relationships.

[0508] For example, as shown in (a) of FIG13A , after a user logs in to a third client using an electronic device, the third client displays a sixth interface via the electronic device. The sixth interface includes six controls, with the sixth control being used to indicate a target bucket. As shown in (b) of FIG13A , the user triggers the sixth control, such as selecting the fifth control and right-clicking the mouse. The third client displays an options page for the sixth control via the electronic device, and the user selects the "Set User Mapping" option on the options page.

[0509] As shown in (c) of FIG13A , in response to a user triggering an operation on the sixth control, the third client displays a third interface on the electronic device, the third interface including a third control and a fourth control. The user performs an input operation on the third control and the fourth control, such as inputting an object user ID on the third control and a file user ID on the fourth control. As shown in (d) of FIG13A , the third client obtains the object user ID and the file user ID in response to the user input operations on the third control and the fourth control, thereby obtaining a mapping relationship.

[0510] It should be noted that in the embodiment of the present application, there is no restriction on the number of third controls and fourth controls on the third interface.

[0511] In this method, by providing the user with a configuration interface for the user mapping relationship (such as the third interface), when the user mapping relationship needs to be configured, the third client can display the configuration interface through the user's electronic device, so that the user can edit the user mapping relationship on the controls of the configuration interface (such as the third control and the fourth control), thereby visualizing the configuration process, which helps to improve operational convenience and user experience.

[0512] Method 1B: Based on the seventh control on the seventh interface, obtain the user mapping relationship.

[0513] The seventh control is used to indicate the storage address of the mapping file, which includes the user mapping relationship.

[0514] For example, as shown in (a) of FIG13B , after a user logs in to a third client using an electronic device, the third client displays a sixth interface on the electronic device. The sixth interface includes six controls, with the sixth control being used to indicate a target storage bucket. As shown in (b) of FIG13B , the user triggers the sixth control, such as selecting the fifth control and right-clicking the mouse. The third client displays an options page for the sixth control on the electronic device, and the user selects the "Set User Mapping" option on the options page.

[0515] As shown in (c) of FIG13B , the third client displays a seventh interface through the electronic device in response to the user's triggering operation on the sixth control. The seventh interface includes the seventh control and the import control. The user triggers the import control, such as clicking the import control. The third client displays the directory where the mapping file is located through the electronic device. After the user selects the mapping file, as shown in (d) of FIG13B , the third client obtains the storage address of the mapping file in response to the user's triggering operation on the import control and displays the storage address on the seventh control. The third client can obtain the mapping file based on the storage address, thereby obtaining the user mapping relationship.

[0516] In this method, by providing the user with an import interface for user mapping relationships (such as the seventh interface), when the user mapping relationship needs to be configured, the third client can display the import interface through the user's electronic device, so that the user can import the pre-edited user mapping relationship into the client through the import interface, which helps to improve the convenience and efficiency of configuring user mapping relationships, and thus helps to improve the user experience.

[0517] Method 2: The third client obtains the user mapping relationship of the target object.

[0518] The user mapping relationship of the target object belongs only to the target object. In other words, the application scope of the user mapping relationship of the target object is the target object.

[0519] It should be noted that for other related instructions of method 2, such as how to obtain the user mapping relationship, please refer to the instructions in method 1 and will not be repeated here.

[0520] In this implementation, the object storage service node provides users with the function of configuring user mapping relationships for objects. In this way, when users need to configure user mapping relationships for some objects in the bucket, they can configure user mapping relationships for these objects. This helps to improve the accuracy of configuring user mapping relationships and thus improve the user experience.

[0521] Step 1202: The third client sends a mapping configuration request to the object storage service node.

[0522] The mapping configuration request includes a user mapping relationship.

[0523] In an embodiment of the present application, after the third client obtains the user mapping relationship, it sends a mapping configuration request to the object storage service node in response to the user's triggering operation on the sending control.

[0524] In one example, the third interface further includes a send control, the send control being used to instruct sending of the mapping configuration request. In another example, the seventh interface further includes a send control, the send control being used to instruct sending of the mapping configuration request.

[0525] Exemplarily, the object storage service node provides a management interface. The third client can send a mapping configuration request to the object storage service node by calling the management interface.

[0526] In an embodiment of the present application, the mapping configuration request includes an indication identifier, which is used to indicate the application scope of the user mapping relationship.

[0527] In one example, the indication identifier is the identifier of the target bucket, based on which the user mapping relationship can be applied to each object in the target bucket. In another example, the indication identifier is the identifier of the target object (i.e., the target identifier), based on which the user mapping relationship can be applied to the target object.

[0528] Step 1203: The object storage service node receives a mapping configuration request sent by the third client.

[0529] Exemplarily, the object storage service node may receive a mapping configuration request sent by a third client through a management interface.

[0530] Step 1204: The object storage service node stores the user mapping relationship in the mapping configuration request.

[0531] In one example, corresponding to method 1 in step 1201, if the user mapping relationship is a user mapping relationship of the target bucket, the object storage service node stores the user mapping relationship in the metadata of the target bucket. For example, the object storage service node may store the user mapping relationship in the metadata of the target bucket based on an identifier indicating that the identifier is the target bucket.

[0532] In another example, corresponding to method 2 in step 1201, if the user mapping relationship is a user mapping relationship of the target object, the object storage service node may store the user mapping relationship in the metadata of the target object. For example, the object storage service node may store the user mapping relationship in the metadata of the target object based on an identifier indicating that the identifier is the target object.

[0533] In the above embodiment, the object storage service node provides users with the function of configuring user mapping relationships. When it is necessary to configure a user mapping relationship for an object, the user sends a mapping configuration request to the object storage service node through a third client. After receiving the mapping configuration request, the object storage service node stores the user mapping relationship in the mapping configuration request, such as: in the metadata of the object or in the metadata of the storage bucket where the object is located, thereby configuring the user mapping relationship for the object.

[0534] On this basis, when a user sends an operation request to the object storage service node through the first client, the object storage service node can determine the object user identifier corresponding to the file user identifier in the operation request based on the user mapping relationship. In addition, when a user sends an operation request to the object storage service node through the second client, the object storage service node can determine the file user identifier corresponding to the object user identifier in the operation request based on the user mapping relationship.

[0535] Optionally, step 1205: the object storage service node sends a tenth response message to the third client.

[0536] The tenth response information is used to indicate a configuration result, which includes a configuration success or a configuration failure.

[0537] It should be noted that, for the relevant description of the tenth response information, reference may be made to the relevant description of the fifth response information in the above step 205, which will not be repeated here.

[0538] Optionally, step 1206: the third client receives the tenth response information sent by the object storage service node.

[0539] In an embodiment of the present application, after the object storage service node stores the user mapping relationship, it sends a tenth response message to the third client to notify the configuration result of the user mapping relationship. This helps the user to promptly understand whether the user mapping relationship is successfully configured, and then, if the configuration is not successful, reconfigure it in time.

[0540] Based on the above embodiment, the object storage service node implements functions such as storage, update, parsing, query and permission check (ACL Permission Check) of file ACL, as well as mapping management of object user identifier and file user identifier, thereby providing complete file ACL features and further improving the file semantics of the object storage service.

[0541] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to realize the above functions, the permission setting device / permission verification device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0542] In the embodiment of the present application, the permission setting device / permission verification device can be divided into functional modules according to the above method. For example, the permission setting device / permission verification device can include various functional modules corresponding to the various functional divisions, or two or more functions can be integrated into one processing module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. There may be other division methods in actual implementation.

[0543] For example, FIG14 shows a possible structural diagram of the permission verification device (denoted as permission verification device 1400) involved in the above embodiment. The actions performed by the permission verification device 1400 are implemented by a computing device (such as an object storage service node) or by executing corresponding software on the computing device. The permission verification device 1400 includes a receiving module 1401 and a permission module 1402. The receiving module 1401 is used to receive an operation request; the operation request includes a target identifier and a target operation type. For example, as shown in step 202 of FIG2 and step 302 of FIG3. The permission module 1402 is used to determine the operation permission corresponding to the operation request based on the file ACL of the target identifier and the file user identifier associated with the operation request; the file ACL includes at least one file user identifier and at least one file permission of the file user identifier. For example, as shown in step 203 of FIG2 and step 303 of FIG3. The permission module 1402 is also used to determine the permission verification result based on the operation permission corresponding to the operation request and the target operation type; the permission verification result is verification success or verification failure. For example, as shown in step 204 of FIG2 and step 204 of FIG3.

[0544] Optionally, the permission module 1402 is specifically configured to: determine the file permission of the file user identifier associated with the operation request according to the file ACL of the target identifier; and determine the file permission of the file user identifier associated with the operation request as the operation permission of the operation request.

[0545] Optionally, the permission module 1402 is specifically used to: determine the file permissions of the file user identifier associated with the operation request based on the file ACL of the target identifier; determine the object permissions of the object user identifier associated with the operation request based on the object ACL of the target identifier; the object ACL of the target identifier includes at least one object user identifier and at least one object permission of the object user identifier; and determine the minimum permission between the file permissions of the file user identifier associated with the operation request and the object permissions of the object user identifier associated with the operation request as the operation permission of the operation request.

[0546] Optionally, the operation request includes a target file user identifier, and the object user identifier corresponding to the target file user identifier is the object user identifier associated with the operation request; the permission module 1402 is specifically used to: determine, based on the user mapping relationship, the object user identifier corresponding to the target file user identifier as the target object user identifier, the user mapping relationship including the correspondence between the target object user identifier and the target file user identifier; determine the object permissions of the target object user identifier based on the object ACL of the target identifier; the object permissions of the target object user identifier are the object permissions of the object user identifier associated with the operation request.

[0547] In another possible implementation, the permission module 1402 is further configured to: when the target file user is not included in the user mapping relationship, send a first response message according to the operation request, where the first response message is used to indicate no permission.

[0548] Optionally, the operation request includes a target object user identifier, which is the object user identifier associated with the operation request; the permission module 1402 is specifically used to: determine the object permission of the target object user identifier based on the object ACL of the target identifier; the object permission of the target object user identifier is the object permission of the object user identifier associated with the operation request.

[0549] Optionally, the operation request includes a target file user identifier, which is the file user identifier associated with the operation request; the permission module 1402 is specifically used to: determine the file permissions of the target file user identifier based on the file ACL of the target identifier; the file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request.

[0550] Optionally, the operation request includes a target object user identifier, and the file user identifier corresponding to the target object user identifier is the file user identifier associated with the operation request. The permission verification device 1400 includes a user management module 1403. The user management module 1403 is configured to: determine, based on a user mapping relationship, the file user identifier of the target object user identifier as the target file user identifier, where the user mapping relationship includes a correspondence between the target file user identifier and the target object user identifier; the permission module 1402 is specifically configured to: determine, based on a file ACL of the target identifier, the file permissions of the target file user identifier; the file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request.

[0551] In another possible implementation, the permission module 1402 is further configured to: when the target object user identifier is not included in the user mapping relationship, send a second response message according to the operation request, where the second response message is used to indicate no permission.

[0552] In another possible implementation, the permission module 1402 is specifically used to: if the operation permission corresponding to the operation request includes the target operation type, determine the permission verification result as a successful verification; if the operation permission corresponding to the operation request does not include the target operation type, determine the permission verification result as a failed verification.

[0553] Optionally, the device further includes an execution module 1404; the execution module 1404 is configured to process the operation request if the permission verification result is successful.

[0554] Optionally, the permission module 1402 is further configured to: if the permission verification result is successful, return the permission verification result according to the operation request.

[0555] Optionally, the permission module 1402 is further configured to: if the permission verification result is a verification failure, return the permission verification result according to the operation request.

[0556] In another possible implementation, when the target node is a target file, the target operation type includes a read operation, a write operation, or a delete operation; when the target node is a target directory, the target operation includes a read operation, a create operation, a delete operation, a move operation, or a rename operation.

[0557] For the detailed description of the above optional methods, please refer to the above method embodiments, which will not be repeated here. In addition, the explanation and description of the beneficial effects of any of the above-mentioned permission verification devices 1400 can refer to the above-mentioned corresponding method embodiments, which will not be repeated here.

[0558] It should be noted that the permission verification device 1400 can also be used to execute the actions executed by the permission setting device 1500 in the following embodiments, which will not be described in detail here. For details, please refer to the relevant description of the permission setting device 1500 below.

[0559] In the embodiment of the present application, the receiving module 1401, the permission module 1402, the user management module 1403, and the execution module 1404 can all be implemented by software or by hardware. For example, the implementation of the permission module 1402 is described below using the permission module 1402 as an example. Similarly, the implementation of the receiving module 1401, the user management module 1403, and the execution module 1404 can refer to the implementation of the permission module 1402.

[0560] As an example of a software functional unit, the permission module 1402 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the permission module 1402 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0561] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0562] As an example of a hardware functional unit, permission module 1402 may include at least one computing device, such as a server. Alternatively, permission module 1402 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0563] The multiple computing devices included in permission module 1402 can be distributed in the same region or in different regions. The multiple computing devices included in permission module 1402 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in permission module 1402 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0564] It should be noted that, in other embodiments, the permission module 1402 can be used to execute any step in the permission verification method, the receiving module 1401 can be used to execute any step in the permission verification method, the user management module 1403 can be used to execute any step in the permission verification method, and the execution module 1404 can be used to execute any step in the permission verification method, or, the steps that the receiving module 1401, the permission module 1402, the user management module 1403 and the execution module 1404 are responsible for implementing can be specified as needed, and the full functions of the permission verification device can be realized by respectively implementing different steps in the permission verification method through the receiving module 1401, the permission module 1402, the user management module 1403 and the execution module 1404.

[0565] Exemplarily, FIG15 shows a possible structural diagram of the permission setting device involved in the above embodiment (referred to as permission setting device 1500). The actions performed by the permission setting device 1500 are implemented by a computing device (such as an object storage service node) or by executing corresponding software implementations by a computing device. The permission setting device 1500 includes a receiving module 1501 and a permission module 1502. The receiving module 1501 is used to receive a file permission setting request; the file permission setting request includes a target identifier and a file ACL of the target identifier, and the file ACL of the target identifier includes at least one file user identifier and file permissions of at least one file user identifier. For example, as shown in step 703 of FIG7. The permission module 1502 is used to store the target identifier file ACL in the object storage service node according to the target identifier; the file ACL of the target identifier is used to determine the file permissions of the file user identifier associated with the operation request. For example, as shown in step 704 of FIG7.

[0566] Optionally, the permission setting device 1500 further includes a user management module 1503. The user management module 1503 is configured to receive a mapping configuration request, the mapping configuration request including a user mapping relationship, the user mapping relationship including a correspondence between at least one file user identifier and at least one object user identifier; and store the user mapping relationship; wherein the user mapping relationship is used to determine the file user identifier corresponding to the object user identifier carried in the operation request, or the user mapping relationship is used to determine the object user identifier corresponding to the file user identifier carried in the operation request.

[0567] Optionally, the permission module 1502 is also used to: receive a file permission update request, the file permission update request includes a target identifier, an updated file ACL, and a setting type for updating the file ACL; the setting type includes at least one of a new type, an overwrite type, a change type, and a deletion type; and update the file ACL of the target identifier according to the target identifier, the updated file ACL, and the setting type for updating the file ACL.

[0568] Optionally, the file ACL includes one or more access control items ACE; the permission module 1502 is further used to: update one or more ACEs of the file ACL; an ACE includes a file user identifier and a file permission of the file user identifier.

[0569] Optionally, the file permission setting request includes a file ACL setting type, and the file ACL setting type includes a new addition type.

[0570] Optionally, the permission module 1502 is specifically configured to: receive a file permission setting request through an object ACL setting interface, where the object ACL setting interface is used to set an object ACL of a target object.

[0571] Optionally, the object storage service node stores an access control policy including a target object, the access control policy including an object ACL of the target object, the object ACL including at least one object user identifier and object permissions of at least one object user identifier; the permission module 1502 is specifically used for: the object storage service node writes the file ACL of the target identifier into the access control policy of the target object according to the target identifier.

[0572] Optionally, the permission module 1502 is also used to: receive a file permission management request; the file permission management request includes a target identifier, and the file permission management request is used to request management of the file ACL of the target identifier; manage the file ACL of the target identifier based on the file permission management request and the target identifier; return a third response information based on the file permission management request, and the third response information is used to indicate the management result of the file ACL.

[0573] Optionally, the file permission management request includes a file permission query request; the permission module 1502 is further configured to: receive the file permission query request, the file permission query request including a target identifier; and return the file ACL of the target identifier in response to the file permission query request.

[0574] Optionally, the file permission management request includes a file permission deletion request; the permission module 1502 is further configured to: receive the file permission deletion request, the file permission deletion request including a target identifier; and delete the file ACL of the target identifier in response to the file permission deletion request.

[0575] For the detailed description of the above optional methods, please refer to the above method embodiments, which will not be repeated here. In addition, the explanation and beneficial effects of any of the above-mentioned permission setting devices 1500 can be referred to the above corresponding method embodiments, which will not be repeated here.

[0576] It should be noted that the permission setting device 1500 can also be used to execute the actions executed by the permission verification device 1400 in the above embodiment, which will not be described in detail here. For details, please refer to the relevant description of the above permission verification device 1400.

[0577] It should be noted that the relevant descriptions of the receiving module 1501, permission module 1502, and user management module 1503 shown in Figure 15 can refer to the relevant descriptions of the receiving module 1401, permission module 1402, user management module 1403, and execution module 1404 shown in the above Figure 14, and will not be repeated here.

[0578] Exemplarily, FIG16 shows a possible structural diagram of the permission setting device involved in the above embodiment (referred to as permission setting device 1600). The actions performed by the permission setting device 1600 are implemented by an electronic device or by executing corresponding software through an electronic device. The permission setting device 1600 includes an acquisition module 1601 and a sending module 1602. The acquisition module 1601 is used to obtain the file ACL of the target identifier; the file ACL includes at least one file user identifier and the file permission of at least one file user identifier. For example, as shown in step 701 of FIG7. The sending module 1602 is used to send a file permission setting request to the object storage service node; the file permission setting request includes the target identifier and the file ACL of the target identifier. For example, as shown in step 702 of FIG7.

[0579] Optionally, the acquisition module 1601 is specifically used to: display a first interface; the first interface includes a first control, and the first control is used to indicate the target object / target node; in response to a trigger operation on the first control, display a second interface, and the second interface includes a second control, and the second control is used to indicate the file ACL; according to the second control on the second interface, obtain the file ACL of the target identifier.

[0580] Optionally, the acquisition module 1601 is further configured to: acquire a user mapping relationship; the user mapping relationship includes a correspondence between at least one file user identifier and at least one object user identifier; and send the user mapping relationship to the object storage service node.

[0581] Optionally, the acquisition module 1601 is specifically used to: display a third interface; the third interface includes a third control and a fourth control corresponding to the third control, the third control is used to indicate the object user identifier, and the fourth control is used to indicate the file user identifier; according to the third control and the fourth control corresponding to the third control, obtain the user mapping relationship.

[0582] Optionally, the sending module 1602 is specifically configured to send a file permission setting request to the object storage service node according to an object ACL setting interface provided by the object storage service node; the object ACL setting interface is an interface for setting the object ACL of the target object.

[0583] Optionally, the file permission setting request includes a file ACL setting type, and the file ACL setting type includes a new addition type.

[0584] Optionally, the acquisition module 1601 is also used to: obtain the updated file ACL; send a file permission update request to the object storage service node, the file permission update setting request includes a target identifier, an updated file ACL, and a setting type for updating the file ACL; the setting type for updating the file ACL includes at least one of a new type, a deletion type, an overwrite type, and a change type.

[0585] Optionally, the device 1600 also includes a receiving module 1603; the sending module 1602 is also used to: send a file permission management request to the object storage service node; the permission management request includes a target identifier, and the permission management request is used to request to manage the file ACL of the target identifier; the receiving module 1603 is used to receive a third response information, and the third response information is used to indicate the management result of the file ACL.

[0586] Optionally, the file permission management request includes a file permission query request; the sending module 1602 is also used to: send a file permission query request to the object storage service node, the file permission query request includes a target identifier; the receiving module 1603 is also used to receive the file ACL of the target identifier sent by the object storage service node.

[0587] Optionally, the file permission management request includes a file permission deletion request; the sending module 1602 is also used to: send a file permission deletion request to the object storage service node, the file permission deletion request includes a target identifier; the receiving module 1603 is also used to receive a fourth response message sent by the object storage service node, the fourth response message is used to indicate the deletion result of the file ACL of the target identifier.

[0588] It should be noted that the relevant descriptions of the acquisition module 1601, sending module 1602 and receiving module 1603 shown in Figure 16 can refer to the relevant descriptions of the receiving module 1401, permission module 1402, user management module 1403 and execution module 1404 shown in the above Figure 14, and will not be repeated here.

[0589] For the detailed description of the above optional methods, please refer to the above method embodiments, which will not be repeated here. In addition, the explanation and beneficial effects of any of the above-mentioned permission setting devices 1600 can be referred to the above corresponding method embodiments, which will not be repeated here.

[0590] The present application also provides a computing device. As shown in Figure 17 , computing device 170 includes a bus 172, a processor 174, a memory 176, and a communication interface 178. Processor 174, memory 176, and communication interface 178 communicate with each other via bus 172. Computing device 170 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 170.

[0591] Bus 172 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG17 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 172 may include a path for transmitting information between various components of computing device 170 (e.g., memory 176, processor 174, and communication interface 178).

[0592] The processor 174 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0593] The memory 176 may include volatile memory, such as random access memory (RAM). The processor 174 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0594] The memory 176 stores executable program code, and the processor 174 executes the executable program code to respectively implement the functions of the aforementioned receiving module 1401, permission module 1402, user management module 1403, and execution module 1404, thereby implementing the permission verification method. In other words, the memory 176 stores instructions for executing the permission verification method.

[0595] Alternatively, the memory 176 stores executable program code, and the processor 174 executes the executable program code to respectively implement the functions of the aforementioned receiving module 1501, the permission module 1502, and the user management module 1503, thereby implementing a permission setting method. In other words, the memory 176 stores instructions for executing a permission setting method.

[0596] The communication interface 178 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 170 and other devices or a communication network.

[0597] It should be noted that the computing device 170 may be a computing device in an object storage service node (as shown in FIG1A ).

[0598] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a cloud server, a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0599] As shown in FIG. 18 , the computing device cluster 180 includes at least one computing device 170 .

[0600] The memory 176 of one or more computing devices 170 in the computing device cluster 180 may store the same instructions for executing the permission verification method. Alternatively, the memory 176 of one or more computing devices 170 in the computing device cluster 180 may store the same instructions for executing the permission setting method.

[0601] It should be noted that for the relevant description of at least one computing device 170 in the computing device cluster shown in FIG18 , reference can be made to the relevant description of the computing device shown in FIG17 , and no further details will be given here.

[0602] It should be noted that the computing device cluster 180 can be used as an object storage service node (as shown in FIG. 1A and FIG. 1B ) to provide cloud services to cloud service tenants.

[0603] The following describes an exemplary connection method of a computing device cluster by taking a computing device cluster that executes the permission verification apparatus 1400 as an example.

[0604] In one possible implementation, one or more computing devices in a computing device cluster (such as the computing device cluster shown in Figure 18) can be connected via a network. The network can be a wide area network or a local area network, etc. Figure 19 shows a possible implementation. As shown in Figure 19, two computing devices (such as computing device 170A and computing device 170B) are connected via a network. Specifically, the network is connected through the communication interface of each computing device. In this type of possible implementation, the memory 106 in the computing device 170A stores instructions for executing the functions of the receiving module 1401, the permission module 1402, and the user management module 1403. At the same time, the memory 106 in the computing device 170B stores instructions for executing the functions of the execution module 1404.

[0605] The connection method between the computing device clusters shown in Figure 19 can be considered to be that the permission verification method provided in this application requires higher computing resources, so the functions implemented by the receiving module 1401, the permission module 1402, and the user management module 1403 are considered to be handed over to the computing device 170A for execution.

[0606] It should be understood that the functionality of computing device 170A shown in FIG19 may also be performed by multiple computing devices 170. Similarly, the functionality of computing device 170B may also be performed by multiple computing devices 170.

[0607] The present application also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to the connection method of the computing device cluster shown in Figure 19. The difference is that the memory 106 of one or more computing devices 170 in the computing device cluster can store the same instructions for executing the permission verification method.

[0608] In some possible implementations, the memory 176 of one or more computing devices 170 in the computing device cluster may also store partial instructions for executing the permission verification method. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for executing the permission verification method.

[0609] It should be noted that for the relevant description of the connection method of the computing device cluster of the execution authority setting device 1500, reference can be made to the description of the connection method of the computing device cluster of the execution authority verification device 1400, which will not be repeated here.

[0610] The embodiment of the present application also provides a gateway device. For relevant descriptions of the gateway device, please refer to the description of the above-mentioned computing device 170, which will not be repeated here.

[0611] The embodiment of the present application further provides a gateway device cluster. For relevant descriptions of the gateway device cluster, please refer to the description of the computing device cluster 170 above, which will not be repeated here.

[0612] An embodiment of the present application also provides an electronic device. As shown in Figure 20 , electronic device 200 includes a bus 202, a processor 204, a memory 206, and a communication interface 208. Processor 204, memory 206, and communication interface 208 communicate with each other via bus 202. Electronic device 200 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in electronic device 200.

[0613] The memory 206 stores executable program code, and the processor 204 executes the executable program code to respectively implement the functions of the aforementioned acquisition module 1601, sending module 1602, and receiving module 1603, thereby implementing the permission setting method. In other words, the memory 206 stores instructions for executing the permission setting method.

[0614] It should be noted that the electronic device 200 may be the electronic device used by the cloud service tenant shown in FIG. 1A and FIG. 1B .

[0615] It should be noted that for other relevant descriptions of the bus 202, processor 204, memory 206 and communication interface 208 of the electronic device 200, reference can be made to the relevant descriptions of the computing device shown in Figure 17 above, and will not be repeated here.

[0616] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the permission verification method.

[0617] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the permission setting method.

[0618] The present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on an electronic device or stored in any available medium. When the computer program product is run on at least one electronic device, the at least one electronic device executes the permission setting method.

[0619] Embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The computer-readable storage medium includes instructions that instruct the computing device to execute the permission verification method.

[0620] Embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The computer-readable storage medium includes instructions that instruct the computing device to execute the permission setting method.

[0621] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by an electronic device, or a data storage device such as a data center that contains one or more available media. The computer-readable storage medium includes instructions that instruct the electronic device to execute the permission setting method.

[0622] The available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid-state drives).

[0623] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A permission verification method, characterized in that: The method is applied to an object storage service node, wherein a target object is stored in a storage bucket of the object storage service node, and the object storage service node is used to map the target object to a target node on a directory tree, wherein the target node is a target file or a target directory, and identifiers of the target node and the target object are both target identifiers; the method comprises: The object storage service node receives an operation request, where the operation request includes the target identifier and the target operation type; The object storage service node determines the operation permission of the operation request according to the file access control list ACL of the target identifier and the file user identifier associated with the operation request, wherein the file ACL of the target identifier includes at least one file user identifier and the file permission of the at least one file user identifier; The object storage service node determines a permission verification result according to the operation permission of the operation request and the target operation type, and the permission verification result is verification success or verification failure.

2. The method according to claim 1, characterized in that The object storage service node determines the operation permission of the operation request according to the file access control list ACL of the target identifier and the file user identifier associated with the operation request, including: The object storage service node determines the file permission of the file user identifier associated with the operation request according to the file ACL of the target identifier; The object storage service node determines the file permission of the file user identifier associated with the operation request as the operation permission of the operation request.

3. The method according to claim 1, characterized in that The object storage service node determines the operation permission of the operation request according to the file access control list ACL of the target identifier and the file user identifier associated with the operation request, including: The object storage service node determines the file permission of the file user identifier associated with the operation request according to the file ACL of the target identifier; The object storage service node determines the object permission of the object user identifier associated with the operation request according to the object ACL of the target identifier; the object ACL of the target identifier includes at least one object user identifier and the object permission of the at least one object user identifier; The object storage service node determines the minimum permission of the file permission of the file user identifier associated with the operation request and the object permission of the object user identifier associated with the operation request as the operation permission of the operation request.

4. The method according to claim 3, characterized in that: The operation request includes a target file user identifier, and the object user identifier corresponding to the target file user identifier is the object user identifier associated with the operation request; The object storage service node determines, according to the object ACL of the target identifier, the object permission of the object user identifier associated with the operation request, including: The object storage service node determines, according to a user mapping relationship, an object user identifier corresponding to the target file user identifier as a target object user identifier, wherein the user mapping relationship includes a correspondence between the target object user identifier and the target file user identifier; The object storage service node determines the object permission of the target object user identifier according to the object ACL of the target identifier; the object permission of the target object user identifier is the object permission of the object user identifier associated with the operation request.

5. The method according to claim 2 or 3, characterized in that: The operation request includes a target file user identifier, and the target file user identifier is a file user identifier associated with the operation request; The object storage service node determines the file permission of the file user identifier associated with the operation request according to the file ACL of the target identifier, including: The object storage service node determines the file permission of the target file user identifier according to the file ACL of the target identifier; The file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request.

6. The method according to claim 2 or 3, characterized in that: The operation request includes a target object user identifier, and a file user identifier corresponding to the target object user identifier is the file user identifier associated with the operation request; The object storage service node determines the file permission of the file user identifier associated with the operation request according to the file ACL of the target identifier, including: The object storage service node determines, according to a user mapping relationship, a file user identifier corresponding to the target object user identifier as a target file user identifier, wherein the user mapping relationship includes a correspondence between the target file user identifier and the target object user identifier; The object storage service node determines the file permissions of the target file user identifier according to the file ACL of the target identifier; the file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request.

7. The method according to any one of claims 1 to 6, characterized in that Before the object storage service node receives the operation request, the method further includes: The object storage service node receives a file permission setting request, where the file permission setting request includes the target identifier and a file ACL of the target identifier; The object storage service node stores the file ACL of the target identifier in the object storage service node according to the target identifier. point.

8. The method according to claim 7, characterized in that The object storage service node receives a file permission setting request, including: The object storage service node receives the file permission setting request through an object ACL setting interface, and the object ACL setting interface is used to set the object ACL of the target object.

9. The method according to claim 7 or 8, characterized in that: The method further comprises: The object storage service node receives a file permission update request, wherein the file permission update request includes the target identifier, an updated file ACL, and a setting type of the updated file ACL; the setting type includes at least one of a new type, an overwrite type, a change type, and a deletion type; The object storage service node updates the file ACL of the target identifier according to the target identifier, the updated file ACL, and the setting type of the updated file ACL.

10. The method according to any one of claims 7 to 9, characterized in that: The method further comprises: The object storage service node receives a file permission deletion request, where the file permission deletion request includes the target identifier; The object storage service node deletes the file ACL of the target identifier in response to the file permission deletion request.

11. The method according to any one of claims 7 to 10, characterized in that: The method further comprises: The object storage service node receives a file permission query request, where the file permission query request includes the target identifier; The object storage service node returns the file ACL of the target identifier in response to the file permission query request.

12. The method according to any one of claims 1 to 11, characterized in that Before the object storage service node receives the operation request, the method further includes: The object storage service node receives a mapping configuration request, wherein the mapping configuration request includes a user mapping relationship, and the user mapping relationship includes a correspondence between the target file user identifier and the target object user identifier; The object storage service node stores the user mapping relationship.

13. The method according to any one of claims 1 to 12, characterized in that: The method further comprises: If the permission check result is that the check is successful, the object storage service node processes the operation request; If the permission check result is that the check fails, the object storage service node returns the permission check result according to the operation request.

14. A permission verification device, characterized in that: The device comprises: A receiving module, configured to receive an operation request, wherein the operation request includes a target identifier and a target operation type; A permission module, configured to determine the operation permission of the operation request according to a file access control list ACL of the target identifier and a file user identifier associated with the operation request, wherein the file ACL of the target identifier includes at least one file user identifier and a file permission of the at least one file user identifier; The permission model is further used to determine a permission verification result according to the operation permission of the operation request and the target operation type, and the permission verification result is verification success or verification failure.

15. The device according to claim 14, characterized in that The permission module is specifically used for: Determine the file permission of the file user identifier associated with the operation request according to the file ACL of the target identifier; The file permission of the file user identifier associated with the operation request is determined as the operation permission of the operation request.

16. The device according to claim 14, characterized in that The permission module is specifically used for: Determine the file permission of the file user identifier associated with the operation request according to the file ACL of the target identifier; Determine the object permission of the object user identifier associated with the operation request according to the object ACL of the target identifier; The object ACL of the target identifier includes at least one object user identifier and object permissions of the at least one object user identifier; The minimum permission among the file permission of the file user identifier associated with the operation request and the object permission of the object user identifier associated with the operation request is determined as the operation permission of the operation request.

17. The device according to claim 16, characterized in that The operation request includes a target file user identifier, and the object user identifier corresponding to the target file user identifier is the object user identifier associated with the operation request; the permission module is specifically used to: According to the user mapping relationship, determining the object user identifier corresponding to the target file user identifier as the target object user identifier, wherein the user mapping relationship includes a correspondence between the target object user identifier and the target file user identifier; Determining the object authority of the target object user identifier according to the object ACL of the target identifier; The object permission of the target object user identifier is the object permission of the object user identifier associated with the operation request.

18. The device according to claim 15 or 16, characterized in that The operation request includes a target file user identifier, and the target file user identifier is a file user identifier associated with the operation request; the permission module is specifically used to: The file permissions of the target file user identifier are determined according to the file ACL of the target identifier; the file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request.

19. The device according to claim 15 or 16, characterized in that The operation request includes a target object user identifier, and the file user identifier corresponding to the target object user identifier is the file user identifier associated with the operation request; the permission module is specifically used to: According to the user mapping relationship, determining the file user identifier corresponding to the target object user identifier as the target file user identifier, wherein the user mapping relationship includes a correspondence between the target file user identifier and the target object user identifier; Determine the file permissions of the target file user identifier according to the file ACL of the target identifier; The file permissions of the target file user identifier are the file permissions of the file user identifier associated with the operation request.

20. The device according to any one of claims 14 to 19, characterized in that The permission module is also used to: receiving a file permission setting request, wherein the file permission setting request includes the target identifier and a file ACL of the target identifier; According to the target identifier, the file ACL of the target identifier is stored in the object storage service node.

21. The device according to claim 20, characterized in that The permission module is specifically used for: The file permission setting request is received through an object ACL setting interface, where the object ACL setting interface is used to set the object ACL of the target object.

22. The device according to claim 20 or 21, characterized in that The permission module is also used to: Receive a file permission update request, the file permission update request including the target identifier, an update file ACL, and a setting type of the update file ACL; the setting type includes at least one of a new addition type, an overwrite type, a change type, and a deletion type; The file ACL of the target identifier is updated according to the target identifier, the update file ACL and the setting type of the update file ACL.

23. The device according to any one of claims 20 to 22, characterized in that The permission module is also used to: receiving a file permission deletion request, wherein the permission deletion request includes the target identifier; In response to the file permission deletion request, the file ACL of the target identifier is deleted.

24. The device according to any one of claims 20 to 23, characterized in that The permission module is also used to: receiving a file permission query request, wherein the permission query request includes the target identifier; In response to the file permission query request, a file ACL of the target identifier is returned.

25. The device according to any one of claims 14 to 24, characterized in that The device further comprises a user management module; the user management module is used for: Receive a mapping configuration request, the mapping configuration request including a user mapping relationship, the user mapping relationship including a correspondence between the target file user identifier and the target object user identifier; The user mapping relationship is stored.

26. The device according to any one of claims 14 to 25, characterized in that The device also includes an execution module; The execution module is configured to process the operation request if the permission verification result is that the verification is successful; The permission module is further configured to return the permission verification result according to the operation request if the permission verification result is the verification failure.

27. A computing device, characterized in that The computing device includes a processor and a memory; The processor of the computing device is configured to execute instructions stored in the memory of the computing device, so that the computing device performs the method according to any one of claims 1 to 13.

28. A computing device cluster, characterized in that: include: at least one computing device, each computing device of the at least one computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 13.

29. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device, the computing device node is caused to perform the method according to any one of claims 1 to 13.

30. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, which, when executed by a computing device, perform the method according to any one of claims 1 to 13.

Images