Multi-tenancy method for file system, and system, engine, device, medium and program product

Abstract

Provided in the embodiments of the present disclosure are a multi-tenancy method for a file system, and a system, an engine, a device, a medium and a program product. In the method, with regard to a multi-tenancy distributed file system, a target user who rents the system may use a service instance to generate an acquisition request for a target file in the system; then, an acquisition permission of the target user for the target file may be verified on the basis of the acquisition request; and when a verification result reflects that the target user has the acquisition permission for the target file, this indicates that the target file is related to requirements of the target user, and the service instance may acquire the target file from the distributed file system. In the method, with regard to a multi-tenancy distributed file system, an acquisition permission of a user for a file is verified, such that files related to respective requirements of different users in the distributed file system can be isolated, and a target user acquires a file related to the requirements of the target user himself / herself, but cannot acquire files related to the requirements of the other users, thereby ensuring security between the files.

Description

[0001] File System Multi-Tenancy Method, System, Engine, Device, Medium, and Program Product This disclosure claims priority to Chinese patent application number 202410040397.0, filed with the China Patent Office on January 9, 2024, entitled "File System Multi-Tenancy Method, System, Engine, Device, Medium, and Program Product," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of storage technology, and more particularly to a file system multi-tenancy method, system, engine, device, medium, and program product. Background: With the generation of massive amounts of data, the use of traditional local file systems often presents problems such as inconvenient data access, management, and maintenance. To improve the management capabilities of massive data, distributed file systems (DFS) have emerged. Furthermore, with the development of cloud computing technology, these distributed file systems can also be provided to users as a cloud service, allowing users to rent DFS to retrieve files relevant to their needs. In practice, a DFS that stores files related to the needs of different users can also support multi-tenancy, meaning that multiple users can lease the same DFS. After leasing the DFS, any user can access all data within the DFS. This means that the user can read both files related to their own needs and files not related to their own needs, that is, files related to the needs of other users. This can lead to security issues between files related to different users' needs. Based on the above description, in DFS multi-tenancy scenarios, improving the security of files related to different users' needs becomes an urgent issue. SUMMARY OF THE INVENTION In view of this, embodiments of the present disclosure provide a file system multi-tenancy method, system, engine, device, medium, and program product to ensure the security of files related to different users' needs in multi-tenancy scenarios. In a first aspect, embodiments of the present disclosure provide a file system multi-tenancy method, comprising: obtaining an acquisition request generated by a service instance used by a target user for a target file in a distributed file system, wherein different users have acquisition permissions for different files in the distributed file system; verifying the target user's acquisition permission for the target file based on the acquisition request; and sending a verification result indicating that the target user has the acquisition permission for the target file to the service instance, so that the service instance acquires the target file.In a second aspect, embodiments of the present disclosure provide a distributed file system, comprising: a file database, a metadata engine, and a service instance used by a target user; different users have access permissions to different files in the file database; the metadata engine is configured to obtain an access request generated by the service instance for a target file in the file database; verify the target user's access permissions to the target file based on the access request; and send a verification result indicating that the target user has access permissions to the target file to the service instance; and the service instance is configured to obtain the target file based on the verification result. In a third aspect, embodiments of the present disclosure provide a metadata engine, comprising: an agent component, configured to obtain an access request generated by the service instance used by the target user for the target file; verify the target user's access permissions to the target file based on the access request; and send a verification result indicating that the target user has access permissions to the target file, so that the service instance obtains the target file. In a fourth aspect, embodiments of the present disclosure provide an electronic device, comprising: a memory configured to store one or more computer instructions, wherein when executed by a processor, the one or more computer instructions implement the file system multi-tenancy method described in the first aspect. The electronic device may further include a communication interface for communicating with other devices or communication systems. In a fifth aspect, embodiments of the present disclosure provide a non-transitory machine-readable storage medium storing executable code. When the executable code is executed by a processor of an electronic device, the processor is enabled to implement at least the file system multi-tenancy method described in the first aspect. In a sixth aspect, embodiments of the present disclosure provide a computer program product. The computer program product includes a computer program or instructions. When executed by a processor, the processor is enabled to implement the file system multi-tenancy method described in the first aspect. In the file system multi-tenancy method provided by embodiments of the present disclosure, different users have access permissions to different files in a distributed file system, meaning that the distributed file system is multi-tenanted to users. Based on this, a target user who rents the system can use a service instance to generate an access request for a target file in the system. The target user's access permissions for the target file can then be verified based on the access request, and the verification result can be fed back to the service instance used by the target user. If the verification result indicates that the target user has access permissions for the target file, the service instance can access the target file from the distributed file system.In the above method, for a target user renting a distributed file system, if the user is verified to have access permissions for the target file, this indicates that the target file is relevant to the target user's needs, not to the needs of other users. The target user can then access the target file normally. For a multi-tenant distributed file system, any user renting the system has access permissions for files relevant to their own needs, but not for files not relevant to their own needs but to the needs of other users. Therefore, permission verification prevents the user from accessing files relevant to other users. This effectively isolates files in the distributed file system according to user needs, thereby ensuring the security of files related to different user needs in the system. BRIEF DESCRIPTION OF THE DRAWINGS To more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly describes the figures used in the embodiments or the prior art descriptions. Obviously, the figures described below represent some embodiments of the present disclosure. Persons skilled in the art can derive other figures based on these figures without inventive effort. Figure 1 is a schematic diagram of the structure of a distributed file system provided by an embodiment of the present disclosure; Figure 2 is a schematic diagram of the structure of another distributed file system provided by an embodiment of the present disclosure; Figure 3 is a schematic diagram of the structure of yet another distributed file system provided by an embodiment of the present disclosure; Figure 4 is a structural diagram of a metadata engine provided by an embodiment of the present disclosure; Figure 5 is a flowchart of a file system multi-tenancy method provided by an embodiment of the present disclosure; Figure 6 is a flowchart of another file system multi-tenancy method provided by an embodiment of the present disclosure; Figure 7 is a schematic diagram of the structure of a file system multi-tenancy device provided by an embodiment of the present disclosure; and Figure 8 is a schematic diagram of the structure of an electronic device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION: To further clarify the objectives, technical solutions, and advantages of the embodiments of the present disclosure, the technical solutions of the embodiments of the present disclosure will be described clearly and completely below in conjunction with the accompanying drawings. It should be understood that the described embodiments are only a portion of the embodiments of the present disclosure, but not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. The terms used in the embodiments of the present disclosure are for the purpose of describing specific embodiments only and are not intended to limit the present disclosure. The singular forms "a", "an", "said" and "the" used in the embodiments of the present disclosure and the appended claims are also intended to include the plural forms. Unless the context clearly indicates otherwise, "a plurality" generally includes at least two, but does not exclude the case of including at least one.It should be understood that the term "and / or" as used herein is merely a description of an association between associated objects, indicating that three possible relationships exist. For example, A and / or B can represent three situations: A exists alone, A and B exists simultaneously, and B exists alone. Furthermore, the character " / " herein generally indicates that the associated objects are in an "or" relationship. Depending on the context, the phrases "if" and "when" as used herein can be interpreted as "upon..." or "when..." or "in response to determining..." or "in response to identifying." Similarly, depending on the context, the phrases "if it is determined" or "if (a stated condition or event) is identified" can be interpreted as "upon determination," "in response to determining," "upon identifying (a stated condition or event)," or "in response to identifying (a stated condition or event)." It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display, etc.) referred to in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant region, and corresponding operation portals are provided for users to choose to authorize or refuse. It should also be noted that the terms "include," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such product or system. Without further limitation, elements defined by the phrase "comprising a..." do not preclude the presence of other identical elements in the product or system comprising the elements. The following detailed description of some embodiments of the present disclosure is provided in conjunction with the accompanying drawings. The following embodiments and features may be combined unless there is a conflict between the embodiments. Furthermore, the sequence of steps in the following method embodiments is provided as an example and is not a strict limitation. Figure 1 is a schematic diagram of the structure of a distributed file system provided in an embodiment of the present disclosure. As shown in Figure 1, the system may include a file database, a metadata engine, and service instances used by target users. The file database is used to store files. Files can be stored as objects in the file database. Optionally, file storage can also be provided to users as a cloud service such as an Object Storage Service (OSS).The files stored in the file database of the distributed file system provided by various embodiments of the present disclosure can be files related to the different needs of multiple users. In other words, the distributed file system provided by various embodiments of the present disclosure is multi-tenant. The relationship between files and user needs can also be understood as users having access rights to files related to their needs. Therefore, in a multi-tenant distributed file system, different users have access rights to different files in the file database. User needs can also be scenario-dependent. Optionally, for example, in an artificial intelligence scenario, a user need may be model training. Files related to this model training need, such as training samples, can be stored in the file database. Another example is an IoT scenario where a user need may be analyzing data collected by IoT devices. Data analysis can be implemented using Function Compute. Files related to this data processing need can be stored in the file database. These files can store data collected by the devices to be analyzed. Another example is a user need for multimedia data processing, such as image processing or audio-to-text conversion. Files related to this data processing need, such as the multimedia data to be processed, can be stored in the file database. Multimedia data processing can also be implemented using Function Compute. Users who rent a distributed file system can access the system using a service instance. Optionally, the service instance can be deployed in the client used by the user. The service instance can be considered a functional module that enables the client to access the distributed file system. Optionally, the client can be a virtual device represented as a container group (pod), and the service instance can be a container deployed in the container group. The container group and its containers all run in an isolated environment. Based on the above description, the operating process of the system provided in this embodiment can be as follows: Any user who rents a distributed file system, referred to as a target user, can use the service instance to access the system. A common access process is for the target user to obtain a target file from a file database. In this case, the target user can trigger an operation on the service instance, causing the service instance to generate a request to obtain the target file. The service instance can further send the request to the metadata engine. Optionally, the same user can generate a request to a service instance running on different clients. Optionally, the metadata engine can transmit the request between service instances using Remote Procedure Calls (RPCs). Afterwards, the metadata engine can verify the target user's access rights to the target file based on the access request to obtain a verification result.The metadata engine's specific authentication process can be found in the relevant description of the following embodiments. The metadata engine can also feed back the verification results to the service instance, which can then determine whether to retrieve the target file based on the verification results. Specifically, if the verification result indicates that the target user has access permissions for the target file, indicating that the target file is relevant to the target user's needs, the service instance can retrieve the target file from the file database. If the verification result indicates that the target user does not have access permissions for the target file, indicating that the target file is irrelevant to the target user's needs, the service instance cannot retrieve the target file. Alternatively, the metadata engine can be implemented as a database, such as a Remote Dictionary Server (redis), a distributed transactional key-value database like KiTV, a database management system (MariaDB), and so on. In this embodiment, for a multi-tenant distributed file system, the target user who rents the system can use the service instance to generate a retrieval request for the target file in the file database. After receiving the retrieval request, the metadata engine can verify the target user's access permissions for the target file and feed back the verification result to the service instance used by the target user. When the verification result indicates that the target user has access permissions for the target file, it indicates that the target file is relevant to the target user's needs, not to other users' needs. Therefore, the target user can access the target file. In a multi-tenant distributed file system, any user who rents the system has access permissions for files relevant to their own needs, but not for files relevant to other users' needs. Therefore, the metadata engine's permission verification function prevents the user from accessing files relevant to other users' needs. This effectively separates and isolates files in the file database according to user needs, thereby ensuring the security of files related to different user needs in the system. As described in the above embodiments, one important function of the metadata engine can be to verify the permissions of the target user. Furthermore, to enable the service instance used by the target user to access the target file, another important function of the metadata engine can be to provide the target file's target metadata to the service instance used by the target user. In one case, when the verification result indicates that the target user has access permissions for the target file, the target metadata can be included in the verification result and sent to the service instance used by the target user. After obtaining the target metadata, the service instance can search for the target file based on the target metadata and obtain the file. For a file database with a large number of files, the use of metadata can speed up the search for the target file.Target metadata can be used to describe attributes such as the target file's storage location, file name, size, and modification time. Alternatively, if the verification result indicates that the target user does not have permission to access the target file, the target metadata will not be fed back to the service instance, preventing the service instance from accessing the target file. This effectively isolates files in the file database and ensures the security of files related to different users' needs. In this embodiment, the metadata engine can directly feed the target metadata required to access the target file back to the service instance. The service instance does not directly access the metadata engine to read metadata, thereby improving the security of data in the metadata engine. The two important functions of the metadata engine mentioned above can be implemented using different components within the metadata engine. Figure 2 is a schematic diagram of the structure of another distributed file system provided by an embodiment of the present disclosure. Based on the embodiment shown in Figure 1, the metadata engine in the system may include a proxy component cluster and a storage component. Optionally, the proxy components within the proxy component cluster may form a consistent hashing ring. Each proxy component within the proxy cluster has permission verification capabilities. Furthermore, the proxy component cluster is designed to improve the efficiency and availability of permission verification. The storage component can store the file identifiers of different files in the file database. Optionally, the file identifiers can be represented as metadata or a key-value pair. The key-value pair consists of a primary key and its corresponding metadata. When a service instance used by a target user generates a request for access, a target proxy component in the proxy component cluster can verify the target user's permissions. Optionally, the service instance used by the target user can determine the target proxy component from the proxy component cluster based on the identities of each proxy component in the proxy component cluster and the identity of the target user. Specifically, the service instance can hash the identities of each proxy component in the proxy component cluster to obtain a first hash value. Simultaneously, a hash is performed on the target user's identity to obtain a second hash value. The proxy component corresponding to the target hash value that is closest to the first hash value is then determined. The proxy component corresponding to the target hash value is the target proxy component. The identities of each proxy component can be assigned when the cloud service provider creates the distributed file system. Optionally, the user's identity can specifically include a user ID (identifier) ​​and / or a user token. Different types of identities can be assigned by relevant components in the distributed file system during the user registration phase.The following details the process by which the target proxy component verifies the target user's permissions: After the target proxy component receives a request from the target user for a target file, the target proxy component can optionally verify the target user's permissions to access the target file based on the target user's identity and the target file's file identifier in the request. Specifically, the target proxy component can determine a set of file identifiers corresponding to the target user based on the target user's identity. If the file identifier of the target file in the request is included in this set of file identifiers, the target proxy component can determine that the target user has permissions to access the target file. The set of file identifiers corresponding to the target user can include the identifiers of different files in the file database for which the target user has permissions to access. This set of file identifiers can be considered a directory, and the target user has permissions to access the files within this directory. To determine the set of file identifiers corresponding to the target user, when the identity includes a user ID and a user token, the target proxy component can first determine the target user's user token based on the target user's user ID, and then further determine the set of file identifiers corresponding to this user token. When the identity includes either a user ID or a user token, the target proxy component can directly determine the set of file identifiers based on the user ID or the user token. The correspondence between a user ID or user token and a file identification set can be set during the user registration phase. The specific process is described in the following related embodiments. Optionally, the file identifications in the set can be directly represented as file metadata, making the file identification set essentially a metadata set. During user registration, a proxy component in the metadata engine can create a metadata set based on the permission information in the registration request. Both the metadata set and the permission information describe which files in the file database the user has access rights to, but they are expressed in different ways. For any registered user, a metadata set can be created for them by any proxy component in the cluster or a specific proxy component. Optionally, the specific proxy component can be selected based on the following criteria: if the hash value corresponding to the identity of a user is closest to the hash value corresponding to the identity of a proxy component in the proxy component cluster, that proxy component is selected to create the metadata set for that user. Optionally, this selection process can be performed by a registration module component in the distributed file system. Based on this, when the target proxy component obtains an acquisition request for the target file, it can directly obtain the metadata set associated with the identity of the target user from the storage component according to the identity of the target user in the acquisition request.If the metadata of the target file in the acquisition request is included in the metadata set corresponding to the target user, the target proxy component can determine that the target user has permission to access the target file. After completing the target user permission verification in the above manner, the service instance used by the target user can directly access the target file based on the target metadata of the target file in the acquisition request. In this embodiment, the target proxy component can use the identity identifier in the acquisition request and the file identifier represented as metadata to verify the target user's permissions. After verification, the service instance used by the target user can also directly access the target file based on the metadata of the target file. Data in the storage component can also be stored in the form of key-value pairs, with the file metadata and the primary key corresponding to the metadata forming a key-value pair. Alternatively, for the file identifiers in the set, the file identifiers can be represented as key-value pairs, and the file identifier set is essentially a key-value pair set. During the user registration phase, the proxy component in the metadata engine can create a key-value pair set based on the permission information in the registration request. For any registered user, the registration component can also select a specific proxy component in the proxy component cluster through hash calculation to create a key-value pair set corresponding to that user. Based on this, when the target proxy component receives a request to obtain a target file, it can determine the key-value pair set corresponding to the target user based on the target user's identity in the request. This key-value pair set includes the primary key and metadata of the file for which the target user has permission to obtain. If the target primary key, represented as a file identifier in the request, is included in the key-value pair set corresponding to the target user, the target user is determined to have permission to obtain the target file. After completing the target user's permission verification in the above manner, the service instance used by the target user can obtain the target file based on the target metadata corresponding to the target primary key. In this embodiment, the target proxy component can verify the target user's permissions using the identity in the request and the file identifier represented as the primary key. After verification, the service instance used by the target user can obtain the target file using the target primary key. Furthermore, using the key-value pair set, the target proxy component can more quickly verify the target user's permissions. Furthermore, this can also improve the speed at which the target user can read files. In the above description, the file identifier set can be created by the proxy component during the user registration phase. Optionally, as shown in Figure 2, the distributed file system may also include a management and control component and a registration component. User registration can be completed collaboratively by the management component, registration component and agent component.The registration process can be further described below in detail: When the identity identifier used in permission verification includes a user ID and a user token, the control component can respond to the target user's registration request to generate the target user's user ID. The control component can send this user ID to the registration component, so that the registration component can further create the target user's user token. When the identity identifier used in permission verification includes a user ID, the control component can respond to the target user's registration request to generate the target user's user ID. When the identity identifier used in permission verification includes a user token, the control component can respond to the target user's registration request and send a registration request to the registration component, so that the registration component can further create the target user's user token. After the control component and / or the registration component create an identity identifier for the target user, the identity identifier can also be sent to a target proxy component in the proxy cluster. The target proxy component can also generate a file identifier set corresponding to the target user based on the permission information in the registration request. The reason why the identity identifier is sent to the target proxy component instead of other proxy components is that the target hash value corresponding to the target proxy component's identity identifier is closest to the second hash value corresponding to the target user's identity identifier. Furthermore, the identity identifier and the set of file identifiers generated by the target proxy component can also be fed back to the control component. Ultimately, the control component can create a client represented as a container group based on the identity identifier and the set of file identifiers. This container group contains a service instance for use by the target service, completing the target user's registration. Since the set of file identifiers can be considered a directory, completing user registration can also be considered as mounting the directory onto the service instance. In this embodiment, the control component, registration component, and proxy component work together to create a container group, allowing users to access the file database using the service instances within the container group. As shown in the embodiment illustrated in FIG2 , the set of file identifiers can be considered a directory, and users have access permissions to files within that directory. As shown in the embodiment illustrated in FIG1 , the service instance used by the user can be a container running in an isolated environment. In practice, container escapes may occur, meaning that the container runs outside the isolated environment. If the container used by the target user escapes, the container can send a permission update request to the proxy component cluster, requesting the target proxy component to mount a new directory. The permission update request may include an identity identifier and updated permission information, and the container may send the permission update request to the target proxy component through hash calculation, so that the proxy component can process it.The updated permission information corresponds to the set of file identifiers for the new files that the target user wishes to access. Furthermore, the target proxy component can verify the validity of the permission update request. Specifically, the target proxy component can determine the target user's reference permission information based on the target user's identity in the permission update request. This reference permission information corresponds to the set of file identifiers created for the target user by the target proxy component during the target user registration phase. If the updated permission information in the permission update request differs from this reference permission information, indicating that the target user wishes to access files related to other users' needs but clearly does not have access permissions for these files, the target proxy component can determine that the permission update request is invalid. The target proxy component will not modify the target user's access permissions for files in the file database, that is, it will not modify the set of file identifiers corresponding to the target user. In practice, the vast majority of updated permission information differs from the reference permission information, and therefore, most permission update requests will be deemed invalid. In this embodiment, when a container representing a service instance escapes and requests permission information update, the target proxy component, using its own permission verification function, can determine whether the target can update the permission information. If the target user cannot update their permission information, the target proxy component can prevent the modification of permission information, thereby ensuring that the target user cannot obtain files related to other users' needs, thereby ensuring the security of files in the file database. In the above embodiments, after the target user passes permission verification, the service instance used by the target user can obtain the target file. To ensure the security of files in the file database, a distributed cache can optionally be used to restrict the service instance from directly obtaining the target file from the file database. The process of obtaining the target file from the cache is described in conjunction with the embodiment shown in FIG3. FIG3 is a schematic diagram of the structure of another distributed file system provided by an embodiment of the present disclosure. Based on the embodiment shown in FIG2, the system may further include: a cache node cluster. Optionally, the cache node cluster may form a consistent hash ring. For a target file that the target user wants to obtain, if the target file is stored in a target cache node in the cache node cluster, indicating that the target file has been used by the target user or a user with the same needs as the target user, the service instance used by the target user can directly obtain the target file from the target cache node. If the target file is not stored in the target cache node, it indicates that the target file has not been used by the target user or a user with the same requirements as the target user. In this case, the target cache node can first read the target file from the file database to the local computer according to the file identifier of the target file in the acquisition request, and then the service instance used by the target user obtains the target file from the target cache node.Regarding the process of the target cache node reading the target file from the file database, the target cache node can optionally locate the target file in the file database based on the file identifier of the target file in the acquisition request and read the file into the target cache node. When the file identifier is in the form of a key-value pair, the target cache node can read the target file into the target cache node based on the target metadata corresponding to the target primary key in the key-value pair. Optionally, the target cache node can be determined by: the service instance used by the target user can be determined based on the identities of each cache node in the cluster and the identity of the target user. Specifically, a hash calculation can be performed on the identity of the cache node to obtain a third hash value, and a hash calculation can be performed on the identity of the target user to obtain a second hash value. The cache node corresponding to the target hash value that is closest to the second hash value is determined among the third hash values, and the target cache node is designated as the target cache node. In this embodiment, regardless of whether the target file is stored in a cache node, the service instance does not directly access the file database when retrieving the target file, thereby ensuring the security of the file in the file database. Furthermore, when the distributed file system provided in the above embodiments is multi-tenanted to a user, the operating process of the file system can also be understood in conjunction with the following content. Assume that a distributed file system is leased to users A and B. User A uses files in the file system for model training. User B uses files in the file system for audio-to-text conversion. The distributed file system's file database may store files 1 through 200. Files 1 through 100 are training samples required by user A. Files 101 through 200 are audio files required by user B. Based on this assumption, user A can use service instance 1 to send a request to proxy component 1 in a proxy component cluster to obtain file 10. Proxy component 1 in the proxy component cluster can then verify whether user A has permission to obtain file 10 based on user A's identity identifier and file identifier of file 10 in the request. After verification, proxy component 1 can return a verification result, including metadata about file 10, to service instance 1, indicating that user A has permission to obtain file 10. Ultimately, service instance 1 can use this metadata as a basis to retrieve file 10 from cache node 1 in the cache node cluster. If there are other users with the same requirements as user A, or user A has used file 10 before, file 10 can be stored in cache node 1. If no user has used file 10, cache node 1 needs to read file 10 from the file database and store it in cache node 1.The verification process of proxy component 1 and the determination process of proxy component 1 and cache node 1 can be found in the descriptions of the above-mentioned related embodiments. When user B, using service instance 2, also sends a request to proxy component 1 for file 10, proxy component 1 can also verify user B's permissions. Because file 10 does not meet user B's audio-to-text requirements, proxy component 1 determines that user B does not have permission to obtain file 10. Proxy component 1 can then provide user B with a verification result indicating that user B does not have permission to obtain file 10. Ultimately, user B is unable to obtain file 10 due to the lack of metadata in service instance 2. As can be seen from the above-mentioned scenario embodiments, the permission verification function of the proxy component in the metadata engine can be used to isolate files in the file system that meet different user requirements, preventing users with one requirement from obtaining files corresponding to other requirements, thereby ensuring the security of files in the file system. Furthermore, any details not described in this embodiment can be found in the relevant descriptions of the above-mentioned embodiments and will not be repeated here. Based on the distributed file systems provided in the above-mentioned embodiments, Figure 4 is a schematic diagram of the structure of a metadata engine provided in an embodiment of the present disclosure. As shown in Figure 4 , the engine may include a proxy component. The proxy component may first obtain an acquisition request for a target file generated by a service instance used by a target user, and then verify the target user's access permissions for the target file based on the acquisition request. When the proxy component determines that the target user has access permissions for the target file, it may send a verification result indicating that the target user has access permissions to the service instance used by the target user. Ultimately, the service instance may then obtain the target file. In this embodiment, the metadata engine's permission verification function prevents the user from accessing files related to other users' needs. This means that files in the file database are partitioned and isolated according to user needs, thereby ensuring the security of files related to different user needs within the system. For details not described in this embodiment, please refer to the relevant descriptions of the above embodiments and will not be repeated here. Optionally, to improve the efficiency of permission verification and ensure high availability of permission verification, a proxy component cluster may be configured in the metadata engine. In the embodiment shown in Figure 4 , the proxy component that determines whether the target user has access permissions for the target file may be a target proxy component in the proxy component cluster. The target proxy component can be determined by the service instance through hash calculation. For details, see the relevant description of the embodiment shown in FIG. 2 , and will not be repeated here. Optionally, as shown in FIG. 4 , the metadata engine may include a storage component for storing the file identifiers of different files in the distributed file system.Optionally, the file identifier can be expressed as metadata or a key-value pair. The key-value pair consists of a primary key and its corresponding metadata. After determining that the target user has permission to obtain the target file, the target proxy component can include the target file's file identifier in the verification result and send it to the service instance used by the target user. The service instance then uses this file identifier as a basis for obtaining the target file. Based on the above embodiments, the following will further describe the operation of the proxy component in the metadata engine when implementing file system multi-tenancy from a process perspective. Figure 5 is a flowchart of a file system multi-tenancy method provided by an embodiment of the present disclosure. This method provided by an embodiment of the present disclosure can be executed by the target proxy component in the metadata engine of a distributed file system. As shown in Figure 1, the method may include the following steps:

[0002] 5101. Obtain an acquisition request generated by a service instance used by a target user for a target file in a distributed file system, wherein different users have acquisition permissions for different files in the distributed file system.

[0003] 5102, verifying the target user's permission to obtain the target file according to the obtain request.

[0004] 5103, sending a verification result indicating that the target user has the permission to obtain the target file to the service instance, so that the service instance can obtain the target file. In this embodiment, the target user can first use the service instance to generate an acquisition request for the target file in the distributed file system, and this acquisition request can be sent to the target proxy component. The target proxy component can then verify the target user's permissions and feedback the verification result to the service instance used by the target user. If the verification result indicates that the target user has the permission to obtain the target file, the service instance can obtain the target file. The specific implementation methods of each step of this embodiment and the technical effects that can be achieved can be found in the relevant descriptions of the above embodiments and will not be repeated here. Figure 6 is a flowchart of another file system multi-tenancy method provided by an embodiment of the present disclosure. As shown in Figure 6, the method may include the following steps:

[0005] S201: Obtain an acquisition request generated by a service instance used by a target user for a target file in a distributed file system, where different users have access permissions to different files in the distributed file system. The specific implementation process of step S201 can be found in the detailed description of the relevant steps in the embodiment shown in FIG. 5 and is not further described here.

[0006] 5202. Determine a file identification set corresponding to the target user according to the identity identifier of the target user in the acquisition request. The file identification set includes the identifiers of the files that the target user has the access permission to.

[0007] 5203. Verify the target user's permission to obtain the target file based on the file identifier set and the file identifier of the target file.

[0008] 5204: Send a verification result indicating that the target user has access permission to the target file to the service instance, allowing the service instance to obtain the target file. The access request received by the target proxy component may include the target user's identity and the file identifier of the target file. The target proxy component may first determine the target user's corresponding file identifier set based on the target user's identity, and then verify the target user's access permission to the target file based on the file identifier set and the file identifier of the target file in the access request. Alternatively, if the file identifier of the target file is included in the target user's corresponding file identifier set, the target user is determined to have access permission to the target file. The target proxy component may generate a verification result indicating that the target user has access permission to the target file and send it to the service instance used by the target user, so that the service instance can obtain the target file user's identity, the contents of the file identifier, and the method for assigning the identifiers. The description of the embodiment shown in FIG. 2 is provided for the user registration process and the specific verification process of the access permission by the proxy component. The description of the embodiment shown in FIG. 2 is also provided for the user registration process and the specific verification process of the access permission by the proxy component. Furthermore, any matters not described in detail in this embodiment may be referred to the relevant descriptions of the above embodiments and are not further elaborated here. Optionally, the service instance used by the target user may be specifically represented by a container. In this case, the container may escape. After the escape occurs, the container may send a permission update request to the proxy component, requesting the proxy component to update its own access permissions. The proxy component can use its own permission verification function to verify whether the container can update its own access permissions, thereby rejecting illegal permission updates from the container and ensuring the security of files in the file system. The following describes in detail a file system multi-tenancy device according to one or more embodiments of the present disclosure. Those skilled in the art will appreciate that these file system multi-tenancy devices can be constructed using commercially available hardware components and configured according to the steps taught in this solution. Figure 8 is a schematic diagram of the structure of a file system multi-tenancy device provided by an embodiment of the present disclosure. As shown in Figure 8, the device may include: an acquisition module 11, configured to obtain an access request generated by a service instance used by the target user for a target file in a distributed file system, where different users have access permissions for different files in the distributed file system; and a verification module 12, configured to verify the target user's access permissions for the target file based on the access request. The sending module 13 is configured to send a verification result indicating that the target user has the permission to obtain the target file to the service instance, so that the service instance obtains the target file.Optionally, the verification module 12 is configured to verify the target user's access permission to the target file based on the target user's identity identifier and the target file's file identifier in the access request. Optionally, the verification module 12 is configured to determine a file identifier set corresponding to the target user based on the identity identifier, the file identifier set including the identifiers of the files for which the target user has access permission. If the file identifier in the access request is included in the file identifier set, the target user is determined to have access permission to the target file. The file identifier set includes a key-value pair set including metadata of the files for which the target user has access permission and primary keys corresponding to the metadata. Optionally, the verification module 12 is configured to determine that the target user has access permission to the target file if a target primary key in the file identifier is included in the key-value pair set. Optionally, the verification module 12 is configured to determine target metadata corresponding to the target primary key within the key-value pair set and send the verification result including the target metadata to the service instance, so that the service instance can access the target file based on the target metadata. Optionally, the device further includes: a registration module 14, configured to respond to a registration request from the target user to generate an identity identifier for the target user; and to create a file identifier set corresponding to the target user based on permission information in the registration request, wherein the permission information describes the target user's access permissions to different files in the distributed file system. Optionally, the service instance is represented by a container running in an isolated environment. The acquisition module 11 is configured to receive a permission update request generated by the container when running outside the isolated environment. The verification module 12 is configured to determine, based on the target user's identity identifier and updated permission information in the permission update request, that the permission update request is invalid, and not modify the target user's access permissions to files in the distributed file system. The device shown in FIG7 can execute the method of the embodiments shown in FIG5 and FIG6. For portions not described in detail in this embodiment, reference is made to the relevant description of the embodiments shown in FIG5 and FIG6. The implementation process and technical effects of this technical solution are described in the embodiments shown in FIG5 and FIG6 and will not be repeated here. In one possible design, the file system multi-tenancy method provided in the above embodiments may be applied to an electronic device. As shown in FIG8 , the electronic device may include a processor 31 and a memory 32. The memory 32 is configured to store a program that supports the electronic device in executing the file system multi-tenancy method provided in the embodiments shown in FIG5 and FIG6 . The processor 31 is configured to execute the program stored in the memory 32.The program includes one or more computer instructions, wherein when executed by the first processor 31, the one or more computer instructions can implement the following steps: obtaining an acquisition request generated by a service instance used by a target user for a target file in a distributed file system, wherein different users have acquisition permissions for different files in the distributed file system; verifying the target user's acquisition permissions for the target file based on the acquisition request; and sending a verification result indicating that the target user has acquisition permissions for the target file to the service instance, so that the service instance acquires the target file. Optionally, the processor 31 is further configured to perform all or part of the steps in the embodiments shown in Figures 5 and 6 . The electronic device may further include a communication interface 33 for communicating with other devices or communication systems. Furthermore, embodiments of the present disclosure provide a computer storage medium for storing computer software instructions used by the electronic device, including a program for executing the file system multi-tenancy method shown in Figures 5 and 6 . Furthermore, embodiments of the present disclosure provide a computer program product. This computer program product includes a computer program or instructions. When the computer program or instructions are executed by a processor, the processor is enabled to implement the steps or functions of the file system multi-tenancy method shown in Figures 5 and 6 . Finally, it should be noted that the above embodiments are intended only to illustrate the technical solutions of the present disclosure and are not intended to limit them. Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art will understand that the technical solutions described in the aforementioned embodiments may be modified or some of the technical features may be replaced with equivalents. Such modifications or replacements do not deviate from the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present disclosure.

Claims

Claims 1. A multi-tenancy method for a file system, wherein, Including: Obtain a fetch request generated by a service instance used by a target user for a target file in a distributed file system, where different users have fetch permissions for different files in the distributed file system; verify the fetch permission of the target user for the target file according to the fetch request; send a verification result indicating that the target user has the fetch permission for the target file to the service instance, so that the service instance can obtain the target file.

2. The method according to claim 1, wherein The verifying the fetch permission of the target user for the target file according to the fetch request includes: verifying the fetch permission of the target user for the target file according to the identity identifier of the target user and the file identifier of the target file in the fetch request.

3. The method according to claim 2, wherein, The verifying the fetch permission of the target user for the target file according to the identity identifier of the target user and the file identifier of the target file in the file fetch request includes: determining a file identifier set corresponding to the target user according to the identity identifier, where the file identifier set includes the identifiers of the files for which the target user has fetch permissions; if the file identifier in the fetch request is included in the file identifier set, it is determined that the target user has the fetch permission for the target file.

4. The method according to claim 3, wherein The file identifier set includes a key-value pair set, where the key-value pair set includes the metadata of the files for which the target user has fetch permissions and the primary keys corresponding to the metadata; the determining that the target user has the fetch permission for the target file if the file identifier in the fetch request is included in the file identifier set includes: determining that the target user has the fetch permission for the target file if the target primary key in the file identifier is included in the key-value pair set; the sending the verification result indicating that the target user has the fetch permission for the target file to the service instance so that the service instance can obtain the target file includes: determining the target metadata corresponding to the target primary key in the key-value pair set; sending the verification result including the target metadata to the service instance so that the service instance can obtain the target file according to the target metadata.

5. The method according to claim 3, wherein The method further includes: responding to a registration request of the target user to generate an identity identifier of the target user; creating a file identifier set corresponding to the target user according to the permission information in the registration request, where the permission information describes the fetch permissions of the target user for different files in the distributed file system.

6. The method according to claim 5, wherein The service instance is manifested as a container running in an isolated environment; The method further includes: receiving a permission update request generated when the container runs outside the isolation environment; determining that the permission update request is invalid according to the identity identifier of the target user and the updated permission information in the permission update request; and not modifying the access permission of the target user to the files in the distributed file system.

7. A distributed file system, wherein, including: a file database, a metadata engine, and a service instance used by a target user; Different users have access permissions to different files in the file database; The metadata engine is configured to obtain an access request generated by the service instance for a target file in the file database; Verify the access permission of the target user to the target file according to the access request; send a verification result indicating that the target user has access permission to the target file to the service instance; The service instance is configured to obtain the target file according to the verification result.

8. The system according to claim 7, wherein, The metadata engine includes a cluster of proxy components; a target proxy component in the cluster of proxy components is configured to verify the access permission of the target user to the target file according to the identity identifier of the target user and the file identifier of the target file in the access request.

9. The system according to claim 8, wherein, The target proxy component is configured to determine a set of key-value pairs corresponding to the target user according to the identity identifier of the target user in the access request, where the set of key-value pairs includes metadata of files to which the target user has access permissions and the primary keys corresponding to the metadata; if the target primary key in the file identifier is included in the set of key-value pairs, determine that the target user has access permission to the target file; read the target metadata corresponding to the target primary key from the set of key-value pairs; the service instance is configured to obtain the target file according to the target metadata.

10. The system according to any one of claims 7 to 9, wherein, The service instance used by the target user is configured to determine a target cache node according to the identity identifiers of the cache nodes in the cache node cluster and the identity identifier of the target user; read the target file from the target cache node included in the cache node cluster.

11. The system according to claim 10, wherein, The target cache node is further configured to, if the target file is not included in the target cache node, read the target file from the file database to the target cache node according to the file identifier of the target file in the access request.

12. A metadata engine, wherein, including: a proxy component configured to obtain an access request generated by a service instance used by a target user for a target file; Verify the access permission of the target user to the target file according to the access request; Send a verification result indicating that the target user has access permission to the target file, so that the service instance obtains the target file.

13. The engine according to claim 12, wherein The engine further includes a cluster of proxy components, and the proxy components in the cluster of proxy components correspond to the target user; The engine further includes: a storage component for storing the file identifiers of different files in the distributed file system, where the file identifiers include metadata or key-value pairs, and the key-value pairs are composed of a primary key and the metadata corresponding to the primary key; and a proxy component for sending the verification result so that the service instance can obtain the target file according to the file identifier of the target file in the verification result.

14. An electronic device, wherein, Comprising: a memory and a processor; wherein, executable code is stored on the memory, and when the executable code is executed by the processor, the processor executes the file system multi-tenancy method according to any one of claims 1 to 6.

15. A non-transitory machine-readable storage medium, wherein, Executable code is stored on the non-transitory machine-readable storage medium, and when the executable code is executed by the processor of the electronic device, the processor executes the file system multi-tenancy method according to any one of claims 1 to 6.

16. A computer program product, wherein Comprising a computer program or instruction, when the computer program or instruction is executed by the processor, the processor is caused to be able to implement the steps in the file system multi-tenancy method according to any one of claims 1 to 6. 17

Images