Permission verification method, device, equipment and cluster

Abstract

The invention discloses a permission verification method, device and equipment and a cluster, and relates to the technical field of storage. The method is applied to an object storage service node, a target object stored by the node is mapped into a target node on a directory tree, and identifiers of the target object and the target node are target identifiers. After a node receives an operation request, because the operation request comprises a target identifier, the node determines an operation authority of the operation request according to a file ACL of the target identifier and a file user identifier associated with the operation request, and determines an authority verification result according to the operation authority of the operation request and a target operation type included in the operation request. The file ACL comprises the file user identifier and the file permission, so that the node can provide fine-grained permission verification conforming to file semantics for the operation request of the target node indicated by the target identifier based on the file ACL, thereby being beneficial to improving the permission verification accuracy of the operation request, and improving the permission verification accuracy of the operation request. And thus, the security and reliability of the file service provided by the node are improved.

Description

Technical Field

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

[0002] File storage is to store data in the form of files on the file storage service node. Users can access files stored on the file storage service node through the file interface provided by the file storage service node. Object storage is to store data in the form of objects on the object storage service node. Users can access objects stored on the object storage service node through the object interface provided by the object storage service node.

[0003] Currently, in order to be compatible with some applications that can only access data through file interfaces (referred to as file applications), object storage service nodes provide file services based on object storage. That is, file applications can access objects stored on object storage service nodes through the file interfaces provided by object storage service nodes. 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. Summary of the invention

[0004] The present application provides a permission verification method, apparatus, device and cluster, so that an object storage service node can provide permission verification that conforms to file semantics, thereby improving the security and reliability of file services provided by the object storage service node.

[0005] 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, 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 comprises: the object storage service node receives an operation request, wherein the operation request comprises a target identifier and a target operation type; the object storage service node determines an 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 comprises at least one file user identifier and a file permission of 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, wherein the permission verification result is verification success or verification failure.

[0006] In this scheme, after receiving the operation request of the target node or target object indicated by the target identifier, the object storage service node determines the operation permission corresponding to the operation request according to 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 representing the file user such as the file user identifier (such as: uid, gid, etc.), the file permission (such as: r, w, x, etc.) and the element representing the file permission, the object storage server node can not only provide fine-grained permission verification that conforms to the 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 the 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, and further improving the user experience.

[0007] In a possible implementation, 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. In this implementation, the file permission of the file user identifier associated with the operation request is directly determined as the operation permission of the operation request, which helps to improve the efficiency of permission verification.

[0008] In another possible implementation, 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 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.

[0009] 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.

[0010] In another possible implementation, the method further includes: when the target file user identifier is not included in the user mapping relationship, the object storage service node sends a first response message according to the operation request, and the first response message is used to indicate that the user has no permission. This helps the user understand the permission verification result.

[0011] In another possible implementation, the operation request includes a target object user identifier, and the target object 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 according to the object ACL of the target identifier, including: the object storage service node determines the object permissions of the target object user identifier according to 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 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 according to the object ACL, which helps to increase the diversity of permission types related to the operation request.

[0012] In another possible implementation, the operation request includes a target file user identifier, and 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 a 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, which helps to increase the diversity of permission types related to the operation request.

[0013] 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.

[0014] In another possible implementation, the method further includes: when the target object user identifier is not included in the user mapping relationship, the object storage service node sends a second response message according to the operation request, and the second response message is used to indicate that the user has no permission. In this way, it is helpful for the user to understand the permission verification result.

[0015] In another possible implementation, the object storage service node determines a permission verification result based on the operation permission and the 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.

[0016] 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 the objects stored in the object storage service node.

[0017] 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 understand the permission verification status in a timely manner.

[0018] In another possible implementation, the method further includes: if the permission check result is a check failure, the object storage service node returns the permission check result according to the operation request. In this way, when the permission check fails, it is helpful for the user to understand the permission check status in time, so as to change the access policy for the target node or target object indicated by the target identifier.

[0019] 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.

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

[0021] 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 comprises: the object storage service node receives a file permission setting request, wherein the file permission setting request comprises a target identifier and a file ACL of the target identifier, wherein the file ACL comprises 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; and the file ACL of the target identifier is used to determine the file permissions of the file user identifier associated with the operation request.

[0022] 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.

[0023] In a possible implementation, the method also 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.

[0024] 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.

[0025] 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.

[0026] In this implementation, the object storage service node provides a file ACL update function. Thus, 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 setting file permissions.

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

[0028] 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 to ensure the uniformity of the format of the file permission update request and the file permission setting request, thereby helping to reduce the user's operation difficulty.

[0029] In another possible implementation, 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. In this implementation, using the object ACL setting interface provided by the object storage service node to receive the file ACL not only helps to reduce the cost of permission setting, but also helps to improve the user experience.

[0030] In another possible implementation, the object storage service node stores an access control policy including a target object, the access control policy of the target object includes an object ACL of the target object, the object ACL of the target object includes 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.

[0031] 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.

[0032] 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.

[0033] In this implementation, the object storage service node provides the user with a file ACL management function, thereby managing the file ACL stored on the object storage service node.

[0034] In another possible implementation, the file permission management request includes a file permission query request; the method further includes: the object storage service node receives the file permission query request, the file permission query request includes a target identifier; the object storage service node responds to the file permission query request and returns a file ACL of the target identifier. 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.

[0035] In another possible implementation, the method further includes: the object storage service node receives a file permission deletion request, the file permission deletion request includes a target identifier; the object storage service node deletes the file ACL of 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 deleting the file ACL stored on the object storage service node.

[0036] 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.

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

[0038] In this scheme, based on the file permission setting function provided by the object storage service node, when the user wants to set file permissions (i.e. permissions that conform to file semantics) for the target node or target object indicated by the target identifier, the user can obtain the file ACL of the target identifier through the electronic device, and send a file permission setting request to the object storage service node, the request including the target identifier (i.e. the identifier of the target node and the target object) and the file ACL of the target identifier, for requesting to configure the file ACL for the target object stored in 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 elements used to characterize the file user and the elements used to characterize the file permissions for the target object, so that the ACP of the target object is more consistent with the file semantics, and the object storage server node can provide fine-grained permission verification that conforms to the file semantics.

[0039] In a possible implementation, obtaining a file ACL of a target identifier includes: displaying a first interface; the first interface includes a first control, the first control is used to indicate a target object / target node; in response to a trigger operation on the first control, displaying a second interface, the second interface includes a second control, the second control is used to indicate a file ACL; and obtaining the file ACL of the target identifier according to the second control on the second interface. In this implementation, the file ACL is obtained through the second control on the second interface, so that the acquisition process is visualized, which helps to improve the convenience of operation and the user experience.

[0040] In another possible implementation, the method further includes: acquiring 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 an object storage service node.

[0041] In this implementation, since when a user sends an operation request through an object interface, the operation request carries an object user identifier, a user mapping relationship is provided for the object storage service node so that 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 enabling, when a user accesses an object through an object interface, permission verification that complies with file semantics is performed through the file user identifier corresponding to the object user identifier and the file ACL.

[0042] 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 according to the third control and the fourth control corresponding to the third control.

[0043] 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.

[0044] 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.

[0045] 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.

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

[0047] In another possible implementation, the method also includes: obtaining an updated file ACL; sending a file permission update request to an object storage service node, wherein 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.

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

[0049] 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.

[0050] In this implementation, the object storage service node provides users with a file ACL management function, so that users can manage the file ACL stored on the object storage service node (such as query, delete, etc.).

[0051] 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 includes a target identifier; and receiving a file ACL of the target identifier sent by the object storage service node.

[0052] In this implementation, a file ACL query function is provided to users based on the object storage service node, so that users can query the file ACL stored on the object storage service node.

[0053] 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 an 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.

[0054] In this implementation, the object storage service node provides the user with a file ACL deletion function, so that the user can delete the file ACL stored on the object storage service node.

[0055] In a fourth aspect, a permission verification method is provided, which is applied to an object storage system, the object storage system comprising an object storage service node and an electronic device, the target object being stored in a storage bucket of the object storage service node, the object storage service node being used to map the target object to a target node on a directory tree, the target node being a target file or a target directory, and the identifiers of the target object and the target node being both target identifiers; the method comprising: the electronic device sending an operation request; the operation request comprising a target identifier and a target operation type; the object storage service node receiving the operation request; the object storage service node determining the operation permission corresponding to the operation request based on a file ACL of the target identifier and a file user identifier associated with the operation request; the file ACL of the target identifier comprising at least one file user identifier and a file permission of at least one file user identifier; the object storage service node determining 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.

[0056] 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.

[0057] In a fifth aspect, a permission setting method is provided, which is applied to an object storage system, the object storage system comprising 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 comprises: the electronic device obtains a file ACL of the target identifier; the file ACL comprises 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 comprises 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 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.

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

[0059] In a sixth aspect, a permission verification device is provided, the device comprising: a functional module for executing any one of the methods provided in the first aspect, 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 at least one file permission of the 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 a successful verification or a failed verification.

[0060] 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, the actions performed by each functional module are executed by hardware or by hardware executing corresponding software. For example, the permission setting device may include a receiving module and a permission module; the receiving module 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, the file ACL includes at least one file user identifier and file permissions of at least one file user identifier; the permission module is used to store the file ACL of the target identifier in an 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.

[0061] In an eighth aspect, a permission setting device is provided, the device comprising: a functional module for executing any one of the methods provided in the third aspect, the actions performed by each functional module are implemented by hardware execution or by hardware execution of corresponding software. For example, the permission setting device may include an acquisition module and a sending module; the acquisition module is used to acquire the 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 sending module 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.

[0062] 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 at least one file permission of the 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.

[0063] 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.

[0064] 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 the target identifier and the 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 permissions of the file user identifier associated with the operation request.

[0065] 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.

[0066] In the eleventh aspect, a processor is provided, which 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.

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

[0068] 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.

[0069] In a 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.

[0070] In the fifteenth aspect, a computing device is provided, comprising 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.

[0071] In the sixteenth aspect, an electronic device is provided, comprising 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.

[0072] 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.

[0073] 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.

[0074] In the nineteenth aspect, a computer program product comprising instructions is provided, which, when executed by a computing device, enables the computing device 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.

[0075] 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.

[0076] 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 different design methods in the above-mentioned first to third aspects, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] Figure 1A A schematic diagram of a system architecture provided for an embodiment of the present application;

[0078] Figure 1B A schematic diagram of another system architecture provided for an embodiment of the present application;

[0079] Figure 2 A flowchart of a permission verification method provided in an embodiment of the present application;

[0080] Figure 3 A flowchart of another permission verification method provided in an embodiment of the present application;

[0081] Figure 4 A flowchart of a method for checking permissions for a read request provided in an embodiment of the present application;

[0082] Figure 5 A flowchart of a write request permission verification method provided in an embodiment of the present application;

[0083] Figure 6 A flowchart of a method for verifying the permissions of a deletion request provided in an embodiment of the present application;

[0084] Figure 7 A flowchart of a method for setting file permissions provided in an embodiment of the present application;

[0085] Fig. 8A A schematic diagram of obtaining a file ACL provided in an embodiment of the present application;

[0086] Figure 8B A schematic diagram of another method for obtaining a file ACL provided in an embodiment of the present application;

[0087] Fig. 9 A flowchart of a method for updating file permissions provided in an embodiment of the present application;

[0088] Fig.10 A flowchart of a file permission management method provided in an embodiment of the present application;

[0089] Fig.11A A schematic diagram of a file permission query provided in an embodiment of the present application;

[0090] Fig. 11B A schematic diagram of deleting file permissions provided in an embodiment of the present application;

[0091] Fig.12 A flowchart of a method for setting a user mapping relationship provided in an embodiment of the present application;

[0092] Fig.13A A schematic diagram of obtaining a user mapping relationship provided in an embodiment of the present application;

[0093] Fig. 13B A schematic diagram of another method for obtaining a user mapping relationship provided in an embodiment of the present application;

[0094] Fig.14 A schematic diagram of a permission verification device provided in an embodiment of the present application;

[0095] Fig.15 A schematic diagram of a permission setting device provided in an embodiment of the present application;

[0096] Fig.16 A schematic diagram of a permission setting device provided in an embodiment of the present application;

[0097] Fig.17 A schematic diagram of a computing device provided in an embodiment of the present application;

[0098] Fig.18 A schematic diagram of a computing device cluster provided in an embodiment of the present application;

[0099] Fig.19 A connection diagram of a computing device cluster provided in an embodiment of the present application;

[0100] Fig. 20 A schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0101] 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.

[0102] 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.

[0103] Furthermore, in the description of the embodiments of the present application, unless otherwise specified, "multiple" 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 items 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 multiple.

[0104] In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", etc. are used to distinguish the same items or similar items with substantially the same functions and effects. Those skilled in the art can understand that the words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not necessarily limit the difference.

[0105] Meanwhile, in the embodiments of the present 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 the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

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

[0107] 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.

[0108] 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.

[0109] File storage service (FSS): is to store data in the form of files on the file storage service node. The file storage service node provides a multi-level tree 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.

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

[0111] 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 the bucket are at the same logical level, removing 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), and users can access data on the object storage service node through the REST API interface.

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

[0113] Bucket: Also referred to as a bucket, it is a container for storing objects on an object storage node. Each bucket has its own storage category, access rights, region, and other attributes.

[0114] Object: It is the basic unit of data storage on an object storage node. An object is a collection of file data and its related attribute information (also called metadata). An object includes key value, metadata and data.

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

[0116] File permissions: refers to permissions that conform to file semantics. In Linux systems, 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.

[0117] The following is an exemplary introduction to the application scenarios of the embodiments of the present application.

[0118] With the development of storage technology, object storage has been proposed in related technologies to more conveniently store unstructured data such as movies, office documents, and images. Object storage uses a flat address space to store data. There is no hierarchy of directories and files in this address space. Therefore, an object storage system can store a large amount of data.

[0119] Currently, in order to be compatible with file applications, object storage service nodes provide file services based on object storage, that is, file services are built on the basis of object storage. However, due to the differences in storage formats, access interfaces, and permission management methods between objects and files, there are significant differences between file semantics and object semantics.

[0120] 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, READ is used to represent the permission to read objects, READ_ACP is used to represent the permission to read access control policies (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.

[0121] 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.

[0122] 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 of a target node or a target object indicated by a target identifier, the operation permission corresponding to the operation request is determined according to the file ACL of the target identifier and the file user identifier associated with the operation request, and the permission verification result is determined based on the relationship between the operation permission corresponding to the operation request and the target operation type. Since the file ACL includes elements representing the file user such as the file user identifier (such as: uid, gid, etc.), the file permission (such as: r, w, x, etc.) and the element representing the file permission, the object storage server node can not only provide a fine-grained permission verification that conforms to the 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 a permission verification that conforms to the 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.

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

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

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

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

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

[0128] Exemplarily, 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 service (MDS) device.

[0129] Optionally, the computing device may be a network device or a terminal device. The network device may include a server, etc. Among them, the server may be a physical server, or two or more physical servers sharing different responsibilities and cooperating with each other to realize various functions of the server. Exemplarily, the server may be a blade server, a high-density server, a rack server or a tower server, etc. The terminal device may include an ultra-mobile personal computer (UMPC), a laptop, a netbook, a desktop computer, an all-in-one computer, etc.

[0130] 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.

[0131] 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.

[0132] Exemplarily, the storage device may include a hard disk drive (HDD), a solid state disk / drive (SSD), etc. It should be noted that the form of the storage device in the embodiment of the present application is not limited, and the above is only an exemplary description. In addition, the number of storage devices in the embodiment of the present application is not limited.

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

[0134] 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.

[0135] In the embodiment of the present application, the client can be installed on the user's electronic device, and the electronic device communicates with the 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 from the supplier through the client, such as renting a storage bucket. After that, the user can store objects in the storage bucket through the client, and manage and access the objects stored in the storage bucket through the client.

[0136] In the embodiment of the present application, the object storage service node is used to provide object services (such as metadata services, storage services, etc.) and file services. Exemplarily, the user can access the data stored on the object storage service node through the object interface provided by the object storage service node. In addition, the user can access the data stored on the object storage service node through the file interface provided by the object storage service node.

[0137] In the 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 bucket.

[0138] 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 you need to simulate object 0 as a file in a folder, you can modify the object identifier of object 0 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.

[0139] 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.

[0140] In the embodiment of the present application, the object storage service node can map objects in the storage bucket to nodes on the directory tree through the hierarchical namespace. The node can be a file or a directory, an object including user data can be mapped to a file, and a simulated folder (i.e., an object not including user data) can be mapped to a directory.

[0141] 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.

[0142] On this basis, after the user sets up 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).

[0143] Exemplarily, 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.

[0144] like Figure 1A , which is a schematic diagram of a system architecture provided in an embodiment of the present application.

[0145] See also 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. The cloud service provider provides cloud services (such as object services, metadata services, and file services, etc.) to users through the object storage service node. The cloud service tenant (i.e., the user) rents the cloud service provided by the cloud service provider through the client on the electronic device.

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

[0147] Terminal devices may include mobile phones, tablet computers, handheld computers, PCs, cellular phones, personal digital assistants (PDAs), wearable devices (such as smart watches, smart bracelets, etc.), smart home devices (such as televisions, etc.), car machines (such as car computers, etc.), 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.

[0148] The network device may include a server, etc. The server may be a physical server, or two or more physical servers with different responsibilities may cooperate with each other to realize various functions of the server. For example, the server may be a blade server, a high-density server, a rack server, or a tower server, etc.

[0149] 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.

[0150] Exemplarily, the storage device of the object storage service node may include storage bucket 1, ..., storage bucket N, where N is a positive integer greater than 1. After the user logs in to the client through the electronic device, the user may rent a storage bucket (e.g., rent storage bucket 1) from the cloud service provider. After renting storage bucket 1, the client may send the 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 storage bucket 1 rented by the user.

[0151] It should be noted that the embodiments of the present application do 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 1AThis is for illustrative purposes only.

[0152] like Figure 1B , which is a schematic diagram of another system architecture provided in an embodiment of the present application.

[0153] See also Figure 1B The object storage service node provides a business interface and a management interface, where the business 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.

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

[0155] Exemplarily, the object storage service node includes a permission module (ACL Permission Check), and the object storage service node sets the file ACL for the object by running the permission module, and performs permission check based on the file ACL when the user accesses the data on the object storage service node. In addition, the object storage service node may also include a user management module, and the object storage service node sets the user mapping relationship for the object or storage bucket by running the user management module.

[0156] 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.

[0157] For ease of understanding, the permission setting method provided in the embodiment of the present application is exemplarily introduced below in combination with the above system architecture and accompanying drawings.

[0158] Figure 2 2 is a flowchart of a method for verifying permissions according to an exemplary embodiment. Exemplarily, the method for verifying permissions may include the following steps 201 to 205.

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

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

[0161] Wherein, an object can be used to indicate a file or a 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.

[0162] 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.

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

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

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

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

[0167] Exemplarily, the object storage service node stores the target element in the form of an object in a storage bucket, and the target element can be user data or a simulated folder. When a user accesses the target element based on the object interface provided by the object storage service node, the target data can be called a target object. When a user accesses the target element based on the file interface provided by the object storage system, the target data is called a target node. Among them, the target node and the target object with a mapping relationship point to the same element (i.e., the target element).

[0168] The following uses a target object and a target node mapped to the target object as an example to exemplify the permission verification method provided in the embodiment of the present application, wherein the identifiers of the target object and the target node are both target identifiers.

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

[0170] 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.

[0171] It should be noted that the relevant description of the file user identification will be described in the subsequent embodiments and will not be repeated here. In addition, 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 first client can be called a file user, which will not be repeated here.

[0172] It should be noted that the first client may be a file system client, or may be other clients that carry a file user identifier when communicating with an object storage service node, and this embodiment of the present application does not impose any limitation on this.

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

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

[0175] 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 a target node / target object indicated by the target identifier.

[0176] It should be noted that, below, an operation request is used to request to perform an operation on a target node indicated by a target identifier as an example to exemplify the embodiments of the present application.

[0177] 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 requests the operation to be performed as the target identifier.

[0178] It should be noted that the embodiments of the present application do not limit how the operation request indicates the target identifier, and the above is merely an exemplary description.

[0179] 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.

[0180] 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.

[0181] 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.

[0182] 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.

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

[0184] 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.

[0185] In an embodiment of the present application, the operation request may further include a target file user identifier. The target file user identifier is an identifier of a target file user who sends the operation request to the object storage service node through the first client. In other words, the target file user is a file user who requests to perform a target operation on the target node.

[0186] Exemplarily, the user enters the file account name and password on the login interface of the first client displayed on the electronic device, and after logging in to the first client, when the first client sends an operation request to the object storage service node through a file interface (such as a POSIX interface), the operation request carries the target file user identifier corresponding to the file account name. The electronic device may store the correspondence between the file account name and the target file user identifier.

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

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

[0189] For example, when the operation request is a write request, the file interface can be write / filesystem / dir / file, where write is used to indicate that the target operation type is a write operation and / filesystem / dir / file is used to indicate the target identifier. When the operation request is a read request, the file interface can be read / filesystem / dir / file, where read is used to indicate that the target operation type is a read operation. When the operation request is a delete request, the file interface can be delete / filesystem / dir / file, where delete is used to indicate that the target operation type is a delete operation.

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

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

[0192] The operation permission corresponding to the operation request is the permission of the target file user to 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 to the target node.

[0193] It should be noted that the operation permission corresponding to the operation request may also be referred to as the operation permission of the operation request, and this embodiment of the present application does not limit this.

[0194] Step 203 may include multiple implementation methods, and the following is exemplified by Method 1 and Method 2.

[0195] 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.

[0196] 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.

[0197] In the 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.

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

[0199] 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.

[0200] 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.

[0201] 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 may also be referred to as the file permission of at least one file user identifier.

[0202] 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.

[0203] In the embodiment of the present application, the file user identifier may include at least one of a user identifier (uid) and a group identifier (gid), wherein 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.

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

[0205] Exemplarily, the file user ID may be the ID of the user who uses the target node, or the ID of the user who creates the target node. The group ID may be the ID of the group that uses the target node, or the ID of the group that creates the target node. The user / group that creates the target node may also be referred to as the owner of the file.

[0206] Optionally, the file permission is a permission in file semantics, or in other words, a permission that complies with file semantics.

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

[0208] In this embodiment, by setting the file ACL to include file permissions, such as: r, w, x, etc., it is possible to add elements for representing file permissions to the file ACL of the target object, that is, to use file semantics to represent permissions, thereby extending the method of representing permissions in the file ACL of the target object, so that the file ACL of the target object is more consistent with file semantics.

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

[0210] When the target node is a directory, r is used to indicate the permission to read the file name under the target node. w is used to indicate the permission to create files / subdirectories under the target node, delete files / subdirectories under the target node, rename files / subdirectories under the directory, and move the location of files / subdirectories under the target node. x is used to indicate the permission to enter the target node.

[0211] In the 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.

[0212] 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 the file permission in the Xml Body.

[0213] In one example, the file ACL of the target object includes <uid> 6668< / uid> and <uid> 6668< / uid> Corresponding <permission> w< / permission> ,in, <uid> 6668< / uid> Used to represent the user ID as 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.

[0214] In another example, the file ACL of the target object includes <gid> 6670< / gid> and <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.

[0215] In yet another example, the file ACL of the target object includes <uid> other< / uid> , <gid> other< / gid> and <uid> other< / uid> , <gid> other< / gid> Corresponding <permission> r< / permission> ,in, <uid> other< / uid> , <gid> other< / gid> Used to represent the user ID and group ID as other. <permission> r< / permission> It is used to indicate that the file permission corresponding to other is read permission, that is, the user to which other belongs has read permission on the target node.

[0216] 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.

[0217] Exemplarily, 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> RX< / permission> .

[0218] It should be noted that, since the owner of the target node has all permissions, the file permissions corresponding to the identifier of the owner of the target node 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.

[0219] 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.

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

[0221] It should be noted that the file permissions corresponding to the target file user ID 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 who requests to perform the target operation on the target node on the target node. In addition, the file permissions corresponding to the target file user ID can also be called the permissions of the target file user ID.

[0222] In an embodiment of the present application, after the object storage service node receives an 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 implementing file permission verification for the target operation requested to be performed by the target file user.

[0223] 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 user identifier of the target file, thereby determining the operation permission corresponding to the operation request.

[0224] 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.

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

[0226] In this method, the file permission corresponding to the target file user identifier is used as the operation permission corresponding to the operation request, so that only the file permission is used to determine the permission verification result, which helps to improve the verification efficiency.

[0227] 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.

[0228] In the embodiment of the present application, when the operation request includes the 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, which will not be described here. For details, please refer to S203b.

[0229] In the 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.

[0230] 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.

[0231] 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.

[0232] 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.

[0233] It should be noted that the number of object user identifiers included in the object ACL is not limited in the embodiment of the present application. In addition, the object permission corresponding to at least one object user identifier may also be referred to as the object permission of at least one object user identifier.

[0234] 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 authority is the authority in the object semantics, or in other words, the authority that complies with the object semantics.

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

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

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

[0238] 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.

[0239] 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.

[0240] 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.

[0241] In an embodiment of the present application, the object storage service node stores a user mapping relationship, and the user mapping relationship includes a correspondence relationship between at least one object user identifier and at least one file user identifier. After 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.

[0242] 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, and the above is only an exemplary description. For example, when reading the object ACL of the target object, if the object user identifier is read, the object storage service node can determine whether the read object user identifier is the object user identifier associated with the operation request according to the user mapping relationship, that is, whether it is the object user identifier that has a corresponding relationship with the target file user identifier.

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

[0244] 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.

[0245] 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.

[0246] 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, which helps the user to adjust the access policy in time.

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

[0248] 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.

[0249] For example, the target object user ID is abc1, and the target object 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.

[0250] 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.

[0251] For example, in combination 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.

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

[0253] In this method, the minimum permission among the file permission corresponding to the target file user identifier and the object permission 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 permission and the object permission, and further provide the user with double permission verification. This helps to improve the standard of permission verification, and further helps to further improve the reliability and security of the file service provided by the object storage service node.

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

[0255] In the above embodiment, the object storage service node provides the user with a file permission verification service, that is, a permission verification service that complies with file semantics. When the user sends an operation request to the object storage service node through the first client, after receiving the operation request, the object storage service node 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, and determines the permission verification result based on the relationship between the operation permission corresponding to the operation request and the target operation.

[0256] Since the file ACL that conforms to the file semantics is used to perform permission verification on the target operation requested by the user, fine-grained permission verification that conforms to the file semantics is implemented for the target operation requested by the user. This not only helps to improve the accuracy of permission verification when the user accesses the file node or directory node, thereby helping to improve the security and reliability of the file service provided by the object storage system, but also helps to diversify the permission verification methods when the user accesses the object, thereby helping to improve the user experience.

[0257] 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.

[0258] 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 check result is successful.

[0259] 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.

[0260] 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.

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

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

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

[0264] 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.

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

[0266] 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.

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

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

[0269] In this embodiment, when the permission verification 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 verification result in a timely manner, thereby helping to improve the user's usage experience.

[0270] 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.

[0271] The following, combined Figure 3 , the differences between the two solutions are explained in detail, and the similarities are not described in detail.

[0272] Figure 3 FIG. 1 is a flowchart of another permission verification method according to an exemplary embodiment. Exemplarily, the permission verification method may include the following steps 301 to 305 .

[0273] 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.

[0274] 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 referred to as an object user, which will not be repeated later.

[0275] It should be noted that the second client may be an object storage client, or may be other clients that carry an object user identifier when communicating with an object storage service node, and this embodiment of the present application does not impose any limitation on this.

[0276] 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.

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

[0278] 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.

[0279] 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 by sending an operation request to the object storage service node.

[0280] In an embodiment of the present application, the operation request may include a target object user identifier. The target object user identifier is an identifier of a target object user who sends the operation request to the object storage service node through the second client. In other words, the target object user is an object user who requests to perform a target operation on the target node.

[0281] Exemplarily, the user enters the object account name and password on the login interface of the second client displayed on the electronic device, and after logging in to the second client, the second client sends an operation request to the object storage service node through the object interface (such as REST API), carrying the target object user identifier corresponding to the object account name. The electronic device may store the corresponding relationship between the object account name and the target object user identifier.

[0282] It should be noted that other related instructions of step 301 can refer to the above-mentioned step 201, which will not be repeated here.

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

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

[0285] For example, when the operation request is a write request, the object interface may be PUT / filesystem / dir / file. When the operation request is a read request, the object interface may be GET / filesystem / dir / file. When the operation request is a delete request, the object interface may be DELETE / filesystem / dir / file.

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

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

[0288] There are multiple implementation methods for step 303 , and the following is an exemplary description using method A and method B.

[0289] 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 identifier associated with the operation request.

[0290] 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.

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

[0292] In one example, the object storage service node uses a token for authentication when communicating with the second client, and the object storage service node stores a correspondence between the token and the object user identifier. The operation request sent by the second client to the object storage service node carries the target token. After receiving the operation request, the object storage service node determines the object user identifier included in the operation request, that is, the target object user identifier corresponding to the target token, based on the target token and the stored correspondence.

[0293] In another example, the object storage service node uses Ak / Sk authentication when communicating with the second client, and the object storage service node stores the correspondence between AK and the object user identifier. The operation request sent by the second client to the object storage service node carries the target access key identifier (access key id, AK). After receiving the operation request, the object storage service node determines the object user identifier included in the operation request based on the target AK and the stored correspondence, that is, the target object user identifier corresponding to the target AK.

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

[0295] 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.

[0296] 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.

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

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

[0299] 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.

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

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

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

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

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

[0305] It should be noted that method A can be considered as another specific implementation method of "determining the operation authority of the operation request according to the file ACL of the target identifier and the file user identifier associated with the operation request".

[0306] 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, so that only the file permission is used to determine the permission verification result, which helps to improve the verification efficiency.

[0307] 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.

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

[0309] 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.

[0310] 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.

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

[0312] 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.

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

[0314] 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.

[0315] 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.

[0316] 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.

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

[0318] 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, so as to determine the permission verification result based on the minimum permission among the file permissions and the 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.

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

[0320] 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.

[0321] In the above embodiment, the object storage service node provides the user with a file permission verification service, that is, a permission verification service that complies with file semantics. When the user sends an operation request to the object storage service node through the second client request, after receiving the operation request, the object storage service node determines the operation permission corresponding to the operation request based on the target identifier indicated by the operation request, the file ACL of the target object 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.

[0322] Since the file ACL that conforms to the file semantics is used to perform permission verification on the target operation requested by the user, fine-grained permission verification that conforms to the file semantics is implemented for the target operation requested by the user. This not only helps to improve the accuracy of permission verification when the user accesses the file node or directory node, thereby helping to improve the security and reliability of the file service provided by the object storage system, but also helps to diversify the permission verification methods when the user accesses the object, thereby helping to improve the user experience.

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

[0324] 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.

[0325] In the embodiment of the present application, the operation request may be a read request. Figure 4 The permission verification process for a read request is illustrated below.

[0326] like Figure 4 As shown, it is a schematic diagram of permission verification of a read request provided in an embodiment of the present application.

[0327] 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 (such as: operation code 403 can be returned). 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. permission verification fails), the object storage service node returns no permission to the second client. If the authentication passes (i.e., the permission verification 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.

[0328] In the embodiment of the present application, the operation request may be a write request. Figure 5 The permission verification process for a write request is illustrated below.

[0329] like Figure 5 As shown, a schematic diagram of permission verification for a write request provided in an embodiment of the present application is provided.

[0330] 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: operation code 403 can be returned). 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 request success 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., target node / target object).

[0331] In the embodiment of the present application, the operation request may be a deletion request. Figure 6 The permission verification process for a deletion request is illustrated by way of example.

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

[0333] The user / file application / object application sends a deletion request to the object storage service node through the second client, such as: 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 (nopermission) to the second client (such as: operation code 403 can be returned). 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 deletion request, and performs authentication (i.e., permission verification) 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 successful request to the second client (e.g., it can return operation code 200) and performs a deletion operation, that is, deletes the target element indicated by the target identifier (i.e., the target node / target object).

[0334] The above embodiment describes a scheme for object storage service nodes to perform permission verification. The present application embodiment also provides another scheme, which is a scheme for configuring object configuration files ACL stored in object storage service nodes, which can also be called a permission setting scheme. Figure 7 , the differences between the two solutions are explained in detail, and the similarities are not described in detail.

[0335] Figure 7 1 is a flowchart of a permission setting method according to an exemplary embodiment. Exemplarily, the permission setting method includes the following steps 701 to 706.

[0336] 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 an object configuration file ACL stored for the object storage service node.

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

[0338] 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, which can be considered as the electronic device performing a certain operation through the third client, or the electronic device performing a certain action during the process of running the third client, which will not be repeated later.

[0339] It should be noted that the electronic device running the third client and the electronic device running the first client / the 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.

[0340] 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 the present application.

[0341] The following is an example of the target object stored in the object storage service node to illustrate the permission setting method provided in the embodiment of the present application.

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

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

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

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

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

[0347] For example, Fig. 8A As shown in (a) of FIG. 1 , after the user logs in to the 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 object / target node. Fig. 8AAs shown in (b), the user performs a trigger operation on the first control, such as: selecting the first control and clicking the right button of the mouse, and the third client displays the option page of the first control through the electronic device and selects the "Set ACL" option in the option page.

[0348] like Fig. 8A As shown in (c) of FIG. 1 , in response to the user's triggering operation on the first control, the third client displays a second interface through the electronic device, where the second interface includes a second control, and the second control is used to indicate the file ACL. The user performs an input operation on the second control, such as: the user enters the file ACL on the second control, such as Fig. 8A As shown in (d), the third client obtains the file ACL in response to the user's input operation on the second control, and displays the file ACL on the second control through the electronic device.

[0349] 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, which helps to improve the operational convenience and the user's experience.

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

[0351] 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 be able to set the file ACL at the same time. That is to say, 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.

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

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

[0354] For example, Figure 8B As shown in (a) of FIG. 1 , after the user logs in to the 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 object / target node. Figure 8B As shown in (b), the user performs a trigger operation on the first control, such as: selecting the first control and clicking the right button of the mouse, and the third client displays the option page of the first control through the electronic device and selects the "Set ACL" option in the option page.

[0355] like Figure 8BAs shown in (c) of FIG. 1 , the third client displays a fifth interface through the electronic device in response to the trigger operation on the first control, and the fifth interface includes the fifth control and the 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, and the user selects the permission file, such as Figure 8B As shown in (d), the third client obtains the storage address of the permission file in response to the user's triggering 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 obtaining the file ACL of the target identifier.

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

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

[0358] The target application code includes file ACL.

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

[0360] In this method, the file ACL is preset in the code of the target application, so that 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.

[0361] 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.

[0362] 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.

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

[0364] 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.

[0365] 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.

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

[0367] Based on the method 1 in the above step 701, the "Set ACL" option in the option page of the first control is associated with the object ACL setting interface, and the object ACL setting interface can be used to set the file ACL and the object ACL. In this case, the same interface can be used to set the file ACL and the object ACL, that is, the object ACL setting interface.

[0368] Exemplarily, the type of the object ACL setting interface may be a REST API interface, and the object ACL setting interface may be PUT / ObjectName? acl. Wherein, "PUT" is used to represent setting (or updating), "ObjectName" is used to represent the target identifier, and "acl" is used to represent the ACL. For example, ObjectName may be filesystem / dir / file, that is, the target identifier may be filesystem / dir / file.

[0369] In the embodiment of the present application, the semantics of adding file ACL to the access control policy of the object is realized by extending the REST API interface of the object. Since the HTTP protocol has good scalability, by extending the REST API interface, setting the file ACL is not only simple to implement, but also low in cost.

[0370] In the 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.

[0371] 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.

[0372] 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.

[0373] 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, and 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.

[0374] In another example, the code of the target application may further include an object ACL setting interface, and 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.

[0375] In this embodiment, the object ACL setting interface provided by the object storage service node is used to set the file ACL. On the one hand, the existing interface of the object storage service node is fully utilized, and the cloud service provider does not need to develop a new interface for the object storage service node specifically for setting the file ACL, which helps to reduce the cost of cloud services. On the other hand, cloud service users do not need to learn and master new interfaces, which helps to reduce the difficulty of setting file ACLs, thereby helping to improve the user experience.

[0376] 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 except the object ACL setting interface, such as the file ACL setting interface.

[0377] 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 the object ACL and file ACL through different interfaces, which helps to ensure the independence of interfaces with different functions.

[0378] 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.

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

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

[0381] 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.

[0382] 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.

[0383] In an embodiment of the present application, after the object storage service node receives a file permission setting request, the object storage service node 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 target object file ACL stored in the object storage service node.

[0384] In one example, the object storage service node can store the file ACL in the file permission setting request in the metadata of the target object indicated by the target identifier. In this way, when performing permission verification on the operation request carrying the target identifier, it helps to improve the accuracy of the file ACL corresponding to the obtained target identifier.

[0385] In another example, the object storage service node may store the file ACL in the file permission setting request in a separate storage device, so that 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.

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

[0387] 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.

[0388] 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.

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

[0390] Exemplarily, 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.

[0391] 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., a single ACE can be updated. 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 update efficiency.

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

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

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

[0395] 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.

[0396] 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 the file ACL of the target object in the same Xml Body.

[0397] In this method, the file ACL is written into the access control policy of the target object, so that 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: Xml Body) to obtain the file ACL and object ACL at the same time, which helps to improve the efficiency of permission verification.

[0398] Optionally, the object storage service node can write each ACE of the file ACL into the access control policy 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.

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

[0400] Exemplarily, after receiving a file permission setting request, the object storage service node may 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 an Xml Body) respectively with the object ACL of the target object.

[0401] 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, which helps to improve the update accuracy of the file ACL, and further helps to improve the convenience and efficiency of the update.

[0402] Exemplarily, when the third client sends a file permission setting request to the object service node through other interfaces except 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.

[0403] In this way, by storing the file ACL as an independent 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 mismatch during storage, thereby helping to ensure the accuracy of the file ACL, and further helping to ensure the accuracy of the ACL permission check performed on the user accessing the target node.

[0404] In the above embodiment, after receiving the 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 storing it 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 achieved to add elements for representing the file user and elements for representing the file permissions to the access control policy of the target object, so that the access control policy of the target object is more consistent with the file semantics, and then the object storage server node can provide fine-grained permission verification that conforms to the file semantics.

[0405] Optionally, step 705: the object storage service node sends a seventh response message to the third client.

[0406] Among them, the seventh response information is used to indicate the file permission setting result.

[0407] It should be noted that, for the relevant description of the seventh response information, reference may 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.

[0408] 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.

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

[0410] 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.

[0411] 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 can reset it in time when the permission setting request is not successfully set, so as to avoid affecting subsequent permission checks.

[0412] 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.

[0413] Fig. 9 The flowchart of a method for updating file permissions is shown according to an exemplary embodiment. Exemplarily, the method for updating file permissions includes the following steps 901 to 906.

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

[0415] 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.

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

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

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

[0419] 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.

[0420] 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.

[0421] 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. Among them, setting a file ACL for an object for a non-first time can be considered as an update of the file ACL that was set for the object for the first time.

[0422] Optionally, the file permission setting request in step 702 may also include a setting type of the file ACL, and the setting type of the file ACL is a new type, which helps to ensure the format uniformity when setting the file ACL and updating the historical file ACL.

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

[0424] 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 modified, updating the file ACL can include <type> modify< / type> .

[0425] 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.

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

[0427] 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.

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

[0429] 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) according to the target identifier, the updated file ACL, and the setting type of the updated file ACL.

[0430] 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.

[0431] 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 may 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 convenience and efficiency of the update.

[0432] In the following, the file ACL of the target object includes ACE1, ACE2 and ACE3, and step 904 is described in an exemplary manner. Among them, ACE1 includes: <uid> 6668< / uid> and <uid> 6668< / uid> Corresponding <permission> w< / permission> ACE2 includes: <gid> 6670< / gid> and <gid> 6670< / gid> Corresponding <permission> rw< / permission> ACE3 includes: <uid> other< / uid> , <gid> other< / gid> and <uid> other< / uid> , <gid> other< / gid> Corresponding <permission> r< / permission> .

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

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

[0435] In another example, updating a file ACL includes <uid> 6668< / uid> and <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.

[0436] In yet another example, updating a file ACL includes <uid> 6669< / uid> and <uid> 6669< / uid> Corresponding <permission> RX< / permission> , the setting type of updating the file ACL is overwrite. Based on this, the object storage service node will " <uid> 6669< / uid> and <uid> 6669< / uid> Corresponding <permission> RX< / permission> "Overwrite ACE1, ACE2, and ACE3 in the history file ACL, that is, the updated file ACL will overwrite the history file ACL.

[0437] In yet another example, updating a file ACL includes <uid> 6668< / uid> and <uid> 6668< / uid> Corresponding <permission> RX< / 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> RX< / 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.

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

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

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

[0441] In the above embodiment, the object storage service node provides the user with the function of updating the 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 identifier of the object / node, 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 identifier of the object / node, the updated file ACL, and the setting type of the updated file ACL, thereby improving the flexibility and convenience of the file ACL setting.

[0442] 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.

[0443] 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 the present embodiment. Below, taking only managing the file ACL of the target object as an example, the permission management method provided in the present embodiment is exemplarily introduced.

[0444] Fig.10 1 is a flowchart of a method for managing rights according to an exemplary embodiment. Exemplarily, the method for managing rights includes the following steps 1001 to 1005.

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

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

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

[0448] 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.

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

[0450] In this example, the object ACL management interface provided by the object storage service node is used to manage file ACLs. On the one hand, the interface provided by the object storage service node is fully utilized. The cloud service provider does not need to develop a new interface for the object storage service node specifically for managing file ACLs, which helps to reduce the cost of cloud services. On the other hand, cloud service users do not need to learn and master new interfaces, which helps to reduce the difficulty of managing file ACLs and thus helps to improve the user experience.

[0451] 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 except the object ACL management interface, such as the file ACL management interface.

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

[0453] 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.

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

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

[0456] For example, Fig.11A As shown in (a) of FIG. 1 , after the user logs in to the third client using the electronic device, the third client displays the first interface through the electronic device, and the first interface includes the first control. Fig.11A As shown in (b), when the user needs to query the file ACL of the target object / target node, the 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 after the third client displays the option page of the first control through the electronic device, the user selects the "Query File ACL" option in the option page, and the third client responds to the user's second trigger operation on the first control and sends a file permission query request to the object storage service node.

[0457] 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 timely understand the content of the file ACL of the target object.

[0458] Optionally, the object ACL management interface includes an object ACL query interface. Exemplarily, the type of the object ACL query interface may be a REST API interface, and the object ACL query interface may be GET / ObjectName? acl&type=fileonly. Among them, "GET" is used to represent the query, "ObjectName?" is used to represent the target identifier, and "acl&type=fileonly" is used to represent the file ACL.

[0459] It should be noted that when file ACL and object ACL are managed synchronously, the object ACL query interface can be GET / ObjectName? acl. Fig.11A The “query file ACL” shown in (b) may be “query ACL”.

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

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

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

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

[0464] For example, Fig. 11B As shown in (a) of FIG. 1 , after the user logs in to the 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. Fig. 11B As shown in (b), when the user needs to delete the file ACL, the user can perform a third trigger operation on the first control, such as: selecting the first control and clicking the right button of the mouse, and 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 in the option page, and the third client responds to the user's third trigger operation on the second control and sends a file permission deletion request to the object storage service node.

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

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

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

[0468] It should be noted that when file ACL and object ACL are managed synchronously, the object ACL deletion interface can be DELETE / ObjectName? acl. Fig. 11BThe "delete file ACL" shown in (b) may be "delete ACL".

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

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

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

[0472] 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.

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

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

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

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

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

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

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

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

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

[0482] In one example, corresponding to the situation 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.

[0483] In another example, corresponding to the situation 2 in the above step 1001, 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.

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

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

[0486] 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.

[0487] In another example, corresponding to the situation 2 in the above step 1001, when the file permission management request includes a file permission deletion request, based on this, such as Fig. 11B As shown in (c), after the user sends a permission deletion request through the third client, after the third client receives the ninth response information sent by the object storage service node, a management interface is displayed through the electronic device, and 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 successful deletion.

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

[0489] In the above embodiment, the object storage service node provides the user with the function of managing file ACL (such as query, deletion, etc.). When the file ACL of the object needs to be managed, 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.

[0490] The above embodiment describes a solution for configuring file ACL and managing file ACL for an object. On this basis, the embodiment of the present application also provides another solution for setting a user mapping relationship for an object.

[0491] Fig.12 The flowchart of a method for setting a user mapping relationship according to an exemplary embodiment is shown. Exemplarily, the method for setting a user mapping relationship includes the following: Step 1201-Step 1206.

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

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

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

[0495] That is, one object user identifier may have a corresponding relationship with one file user identifier, or one object user identifier may have a corresponding relationship with multiple file user identifiers.

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

[0497] It should be noted that the user mapping relationship may include one or more groups of corresponding relationships, which is not limited in the embodiments of the present application.

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

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

[0500] The target object is stored in the target bucket, 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.

[0501] In this way, 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 the bucket to achieve the configuration of user mapping relationships for each object in the bucket, which helps to improve the convenience of configuring user mapping relationships.

[0502] Optionally, there are multiple implementations for how to obtain the user mapping relationship, which are exemplified below by way of way 1A to way 1B.

[0503] Mode 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.

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

[0505] 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.

[0506] For example, Fig.13A As shown in (a) of FIG. 1 , after the user logs in to the third client using an electronic device, the third client displays a sixth interface through the electronic device. The sixth interface includes six controls, and the sixth control is used to indicate a target bucket. Fig.13A As shown in (b), the user performs a trigger operation on the sixth control, such as: the user selects the fifth control and clicks the right button of the mouse, and after the third client displays the option page of the sixth control through the electronic device, the user selects the "Set user mapping relationship" option in the option page.

[0507] like Fig.13A As shown in (c) of FIG. 1 , the third client displays a third interface through the electronic device in response to the user's triggering operation on the sixth control, and the third interface includes a third control and a fourth control. The user performs input operations on the third control and the fourth control, such as: the user enters an object user identifier on the third control and enters a file user identifier on the fourth control, such as Fig.13AAs shown in (d), the third client obtains the object user identifier and the file user identifier in response to the user's input operation on the third control and the fourth control, thereby obtaining a mapping relationship.

[0508] 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.

[0509] 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.

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

[0511] Among them, the seventh control is used to indicate the storage address of the mapping file, and the mapping file includes the user mapping relationship.

[0512] For example, Fig. 13B As shown in (a) of FIG. 1 , after the user logs in to the third client using an electronic device, the third client displays a sixth interface through the electronic device. The sixth interface includes six controls, and the sixth control is used to indicate the target storage bucket. Fig. 13B As shown in (b), the user performs a trigger operation on the sixth control, such as: the user selects the fifth control and clicks the right button of the mouse, and after the third client displays the option page of the sixth control through the electronic device, the user selects the "Set user mapping relationship" option in the option page.

[0513] like Fig. 13B As shown in (c) of FIG. 1 , the third client displays the seventh interface through the electronic device in response to the user's triggering operation on the sixth control, and the seventh interface includes the seventh control and the import control. The user performs a triggering operation on the import control, such as: the user clicks the import control, and 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 FIG. Fig. 13B As shown in (d), 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.

[0514] 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 the user mapping relationship, and thus helps to improve the user experience.

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

[0516] 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.

[0517] 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, which will not be repeated here.

[0518] 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.

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

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

[0521] In the 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.

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

[0523] 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.

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

[0525] In one example, the indication is the identification 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 is the identification of the target object (i.e., the target identifier), based on which the user mapping relationship can be applied to the target object.

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

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

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

[0529] In one example, corresponding to method 1 in step 1201, if the user mapping relationship is a user mapping relationship of a 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.

[0530] In another example, corresponding to the 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 the identifier indicating the identifier as the target object.

[0531] In the above embodiment, the object storage service node provides the user with the function of configuring user mapping relationships. When the user mapping relationship needs to be configured 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 realizing the configuration of the user mapping relationship for the object.

[0532] On this basis, when the 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 the 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.

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

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

[0535] 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.

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

[0537] 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 reconfigure it in time if the configuration is not successful.

[0538] Based on the above embodiments, 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, so as to provide complete file ACL features and further improve the file semantics of the object storage service.

[0539] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, the permission setting device / permission verification device includes a hardware structure and / or software module 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 in this document, 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.

[0540] The embodiment of the present application can exemplarily divide the functional modules of the permission setting device / permission verification device according to the above method. For example, the permission setting device / permission verification device may include various functional modules corresponding to the various functional divisions, or two or more functions may be integrated into one processing module. The above 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.

[0541] For example, Fig.14 A possible structural diagram of the permission verification device (referred to as permission verification device 1400) involved in the above embodiment is shown. 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 by a 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, Figure 2 Step 202 shown, Figure 3 Step 302 shown. Permission module 1402 is used to determine the operation permission corresponding to the operation request according to 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, Figure 2 Step 203 shown, Figure 3 Step 303 shown. The permission module 1402 is also used to determine the permission verification result according to 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, Figure 2 Step 204 shown, Figure 3 Step 204 is shown.

[0542] Optionally, the permission module 1402 is specifically used 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.

[0543] 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.

[0544] 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 a user mapping relationship, that the object user identifier corresponding to the target file user identifier is the target object user identifier, the user mapping relationship including a correspondence between the target object user identifier and the target file user identifier; determine, based on an object ACL of the target identifier, an object permission of the target object user identifier; the object permission of the target object user identifier is the object permission of the object user identifier associated with the operation request.

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

[0546] 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 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] Optionally, the operation request includes a target file user identifier, which is a 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.

[0548] 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 module 1402 is specifically used to: determine the file user identifier of the target object user identifier as the target file user identifier based on a user mapping relationship, the user mapping relationship including a correspondence between the target file user identifier and the target object user identifier; 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.

[0549] In another possible implementation, the permission module 1402 is further used 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.

[0550] 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.

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

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

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

[0554] 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.

[0555] 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.

[0556] 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 embodiment, which will not be described in detail here. For details, please refer to the relevant description of the permission setting device 1500 below.

[0557] 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 be implemented by software or by hardware. Exemplarily, the implementation of the permission module 1402 is introduced below by taking 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.

[0558] As an example of a software functional unit, the permission module 1402 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned 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 (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 a data center or multiple data centers with similar geographical locations. Among them, usually a region may include multiple AZs.

[0559] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0560] As an example of a hardware functional unit, the permission module 1402 may include at least one computing device, such as a server, etc. Alternatively, the permission module 1402 may also be a device 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.

[0561] The multiple computing devices included in the permission module 1402 can be distributed in the same region or in different regions. The multiple computing devices included in the permission module 1402 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the 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.

[0562] 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 are 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.

[0563] For example, Fig.15 A possible structural diagram of the permission setting device involved in the above embodiment (referred to as permission setting device 1500) is shown. The actions performed by the permission setting device 1500 are implemented through a computing device (such as an object storage service node) or through a computing device executing corresponding software. 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, Figure 7 Step 703 shown. 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 permission of the file user identifier associated with the operation request. For example, Figure 7 Step 704 is shown.

[0564] Optionally, the permission setting device 1500 further includes a user management module 1503. The user management module 1503 is used to receive a mapping configuration request, the mapping configuration request includes a user mapping relationship, the user mapping relationship includes a correspondence relationship between at least one file user identifier and at least one object user identifier; 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.

[0565] 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 update 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 update file ACL, and the setting type for updating the file ACL.

[0566] 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.

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

[0568] Optionally, the permission module 1502 is specifically used 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.

[0569] Optionally, the object storage service node stores an access control policy including a target object, the access control policy of the target object includes an object ACL of the target object, the object ACL of the target object includes 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.

[0570] 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.

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

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

[0573] 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 of any of the above-mentioned permission setting devices 1500 and the description of the beneficial effects can refer to the above-mentioned corresponding method embodiments, which will not be repeated here.

[0574] 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.

[0575] Need to explain, Fig.15 For the related description of the receiving module 1501, the permission module 1502, and the user management module 1503 shown in FIG. Fig.14 The related descriptions of the receiving module 1401, the permission module 1402, the user management module 1403 and the execution module 1404 are not repeated here.

[0576] For example, Fig.16 A possible structural diagram of the permission setting device (referred to as permission setting device 1600) involved in the above embodiment is shown. The actions performed by the permission setting device 1600 are implemented by an electronic device or by executing corresponding software by 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 at least one file permission of the file user identifier. For example, Figure 7 Step 701 shown. Sending module 1602 is 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. For example, Figure 7 Step 702 is shown.

[0577] 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 a 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 a file ACL; according to the second control on the second interface, obtain the file ACL of the target identifier.

[0578] Optionally, the acquisition module 1601 is further used 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.

[0579] 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 an object user identifier, and the fourth control is used to indicate a file user identifier; according to the third control and the fourth control corresponding to the third control, obtain a user mapping relationship.

[0580] Optionally, the sending module 1602 is specifically used to: send a file permission setting request to the object storage service node according to the 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.

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

[0582] 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.

[0583] 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.

[0584] 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.

[0585] 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.

[0586] Need to explain, Fig.16 For the related description of the acquisition module 1601, the sending module 1602 and the receiving module 1603 shown in FIG. Fig.14 The related descriptions of the receiving module 1401, the permission module 1402, the user management module 1403 and the execution module 1404 are not repeated here.

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

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

[0589] The bus 172 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.17 The bus 172 may include a path for transmitting information between various components of the computing device 170 (eg, the memory 176, the processor 174, and the communication interface 178).

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

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

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

[0593] Alternatively, the memory 176 stores executable program codes, and the processor 174 executes the executable program codes 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. That is, the memory 176 stores instructions for executing a permission setting method.

[0594] 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 communication networks.

[0595] It should be noted that the computing device 170 may be an object storage service node (eg Figure 1A A computing device as shown).

[0596] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, for example, 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 smart phone.

[0597] like Fig.18 As shown, the computing device cluster 180 includes at least one computing device 170 .

[0598] The memory 176 in 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 in one or more computing devices 170 in the computing device cluster 180 may store the same instructions for executing the permission setting method.

[0599] Need to explain, Fig.18 For the description of at least one computing device 170 in the computing device cluster, please refer to Fig.17 The relevant description of the computing device shown is not repeated here.

[0600] It should be noted that the computing device cluster 180 can be used as an object storage service node (such as Figure 1A , Figure 1B ), used to provide cloud services to cloud service tenants.

[0601] In the following, the connection method of the computing device cluster is exemplarily introduced by taking the computing device cluster of the execution authority verification apparatus 1400 as an example.

[0602] In one possible implementation, a computing device cluster (e.g., Fig.18 One or more computing devices in the computing device cluster shown in the figure may be connected via a network, which may be a wide area network or a local area network. Fig.19 A possible implementation is shown. Fig.19 As shown, two computing devices (such as computing device 170A and computing device 170B) are connected via a network. Specifically, the network is connected via 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.

[0603] Fig.19 The connection method between the computing device clusters shown 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.

[0604] It should be understood that Fig.19The functionality of computing device 170A shown in FIG. 1 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.

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

[0606] 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 may jointly execute instructions for executing the permission verification method.

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

[0608] 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.

[0609] The embodiment of the present application further provides a gateway device cluster. For the relevant description of the gateway device cluster, reference may be made to the description of the computing device cluster 170 above, which will not be repeated here.

[0610] The present application also provides an electronic device. Fig. 20 As shown, the electronic device 200 includes: a bus 202, a processor 204, a memory 206 and a communication interface 208. The processor 204, the memory 206 and the communication interface 208 communicate through the bus 202. The electronic device 200 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the electronic device 200.

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

[0612] It should be noted that the electronic device 200 may be Figure 1A , Figure 1BElectronic devices used by cloud service tenants are shown.

[0613] It should be noted that other related descriptions of the bus 202, processor 204, memory 206 and communication interface 208 of the electronic device 200 can refer to the above Fig.17 The relevant description of the computing device shown is not repeated here.

[0614] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or 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 verification method.

[0615] The embodiment of 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.

[0616] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be a software or 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.

[0617] The embodiment of 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 a computing device or a data storage device such as a data center that includes one or more available media. The computer-readable storage medium includes instructions that instruct the computing device to execute the permission verification method.

[0618] The embodiment of 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 a computing device or a data storage device such as a data center that includes one or more available media. The computer-readable storage medium includes instructions that instruct the computing device to execute the permission setting method.

[0619] The embodiment of 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 the electronic 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 electronic device to execute the permission setting method.

[0620] The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state drive), etc.

[0621] 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 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.

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