A User Authentication and File Sharing Method Based on Virtual Directory

Abstract

This invention discloses a user authentication and file sharing method based on a virtual directory, comprising: connecting to backend storage via a FUSE gateway to generate a virtual directory structure combining username and shared bucket; the file gateway obtaining all shared mount information and user authentication information using the extended attributes of the virtual directory; upon receiving a user mount request, generating a specific key based on the user account information, obtaining user authentication information and verifying identity through the extended attributes; after successful authentication, querying the shared bucket information to be accessed based on the shared mount information and the user request; then obtaining the shared bucket mount information using the extended attributes, determining the final access path, and completing file sharing and permission verification. This method does not rely on local configuration file synchronization, improves resource utilization, and simplifies the authentication and sharing process.

Description

Technical Field

[0001] This invention relates to distributed storage technology, and in particular to a user authentication and file sharing method based on a virtual directory. Background Technology

[0002] Samba is open-source software based on the SMB (Server Message Block) protocol, which can also be a trademark. SMB is a protocol used on Linux and UNIX systems for sharing resources such as files and printers. This protocol is client / server based, allowing clients to access shared resources on the server. When Windows is the client and CentOS is the server, Samba enables Windows to access Linux resources, facilitating data exchange between the two systems. The Samba service has become the best choice for sharing files between Linux and Windows systems; however, between Linux systems, file sharing typically uses the NFS protocol and the kernel's NFSD service.

[0003] Samba gateway architecture as follows Figure 1 As shown, a Samba gateway consists of a main process and multiple child processes. After gateway initialization, there is only one main process; upon receiving a user connection, a child process is spawned to handle user login authentication and I / O requests. Therefore, different users perform I / O processing through different Samba child processes, and different Samba child processes cannot share data.

[0004] Samba gateways support connecting to local file systems, allowing different Samba child processes to share the local file system with different clients.

[0005] Fuse (filesystem in userspace) is a user-space file system. With the support of the Fuse kernel module, developers only need to implement specific file operations based on the interfaces provided by Fuse to create a file system. Because its main implementation code resides in user space and does not require recompiling the kernel, this brings numerous conveniences to developers.

[0006] Fuse consists of a kernel module and a user-space daemon (hereinafter referred to as the fuse daemon). When the kernel module is loaded, it is registered as a Fuse filesystem driver within the Linux virtual filesystem. Additionally, a block device, / dev / fuse, is registered. This block device acts as a bridge between the fuse daemon and the kernel; the fuse daemon reads fuse requests through / dev / fuse, processes them, and writes the response to / dev / fuse.

[0007] Figure 2 The architecture of Fuse is explained in detail. When an application is mounted on the Fuse file system and executes system calls, VFS routes these operations to the fuse driver. The fuse driver creates a fuserequest structure and stores the request in a request queue. At this time, the process executing the operation is blocked, while the fuse daemon reads / dev / fuse to retrieve the request from the kernel queue and submits the operation to the underlying file system (such as EXT4 or F2FS). After processing the request, the fuse daemon writes the reply back to / dev / fuse, and the fuse driver marks the request as completed, finally waking up the user process.

[0008] File extended attributes are designed to allow users to flexibly set custom attributes for files. Extended attributes are name:value pairs associated with files and directories, used to provide additional file system functionality, such as ACLs. Users with read permissions for a file or directory can see its extended attributes. The space required for extended attributes is calculated from the file owner's disk quota. Currently, the file systems that support extended attributes on Linux include: ext2, ext3, ext4, XFS, JFS, and reiserfs. An example of viewing file extended attributes is shown below. Figure 3 As shown.

[0009] The Samba gateway authenticates users and verifies file sharing by reading a local configuration file. The `smb.conf` file is the core configuration file for the Samba service, defining information such as shared directories and user permissions. In most Linux distributions, the `smb.conf` file is typically located in the ` / etc / samba / ` directory. Figure 4This is a simple smb.conf file example that defines a shared directory named `shared_folder` at the path ` / path / to / shared / folder`. This directory allows read and write operations (`read only = no`) and can be browsed by other users (`browsable = yes`). The `valid users` option specifies the list of users who can access this shared directory.

[0010] In Samba, user permissions are managed through Samba users, and Samba user accounts need to be created for users who want to access shared directories.

[0011] Since Samba verifies user login authentication information by reading local configuration, in multi-gateway cluster scenarios, configuration information needs to be synchronized periodically between different server nodes to ensure consistency of login authentication.

[0012] The existing Samba authentication login process is as follows: Figure 5 As shown. The CIFS client login process specifically includes:

[0013] (1) The client (Windows) sends a mount request to the main Samba process. After receiving the request, the main Samba process will spawn a child process to respond to the user's connection request.

[0014] (2) After the connection is successfully established, the client sends the username / password and other authentication information to the Samba subprocess. The Samba subprocess obtains the user's authentication information through the local configuration file and verifies it with the authentication request sent by the user.

[0015] (3) After the authentication verification is successful, the client sends the mount path to the Samba child process. The Samba child process confirms whether the shared path information is correct through the local configuration file. If the shared path information is correct, it replies with a response that the mount is successful.

[0016] (4) After the shared path is successfully mounted, the client sends an IO read / write request, and the Samba child process responds to the client's request and reads and writes data from the corresponding shared directory.

[0017] In a distributed storage cluster, the storage gateway needs to access data in the backend storage cluster through a specific client. Therefore, in a multi-process file gateway scenario, each gateway process needs to load a storage cluster client, which consumes significant memory and CPU resources, especially in scenarios with a large number of logged-in users. Furthermore, in distributed storage clusters, file gateways are typically deployed on multiple servers. If the relevant configurations are stored in local files on the servers, modifying the configuration requires simultaneous modifications to the configuration files on multiple servers, leading to real-time data synchronization issues.

[0018] It should be noted that the information disclosed in the background section above is only for understanding the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0019] The main objective of this invention is to overcome the deficiencies in the aforementioned background technology and provide a user authentication and file sharing method based on a virtual directory.

[0020] To achieve the above objectives, the present invention adopts the following technical solution:

[0021] A user authentication and file sharing method based on a virtual directory includes:

[0022] Connect to the backend storage via the FUSE gateway and generate a virtual directory structure that combines usernames and shared buckets;

[0023] The file gateway obtains all shared mount information and user authentication information through the extended attributes of virtual directories;

[0024] After receiving a user's mount request, the file gateway generates a specific key by combining the user's account information, obtains the user's account authentication information through the extended attributes of the virtual directory, and performs user identity verification based on the authentication information.

[0025] After user authentication is successful, the file gateway queries the shared bucket information that the user needs to access based on the obtained shared mount information and the user's mount request.

[0026] The file gateway obtains the mount information of the shared bucket by utilizing the extended attributes of the virtual directory, determines the final access path, and completes file sharing and permission verification.

[0027] A computer program product includes a computer program that, when executed by a processor, implements the aforementioned user authentication and file sharing method based on a virtual directory.

[0028] The present invention has the following beneficial effects:

[0029] This invention proposes a user authentication and file sharing method based on a virtual directory. Compared with the prior art, the significant technical advantages of this invention include: on the one hand, the extended attributes of the virtual directory are used to obtain configuration information and authentication information, avoiding the problem of information synchronization between multiple servers; on the other hand, through the virtual directory, client aggregation between various gateway subprocesses is realized, improving resource utilization.

[0030] The method of this invention simplifies the authentication and sharing process of a file gateway by using virtual directories and extended file directory attributes. This avoids configuration file synchronization issues and improves memory reuse efficiency through resource sharing, thereby enhancing overall performance. Furthermore, the virtual directory supports obtaining relevant information through extended attributes without modifying configuration files or directly connecting to backend storage, simplifying the gateway architecture and processing flow.

[0031] Other beneficial effects of the embodiments of the present invention will be further described below. Attached Figure Description

[0032] Figure 1 This is a diagram of the Samba gateway architecture.

[0033] Figure 2 This is the FUSE architecture diagram.

[0034] Figure 3 This is an example image showing how to view file extension attributes.

[0035] Figure 4 This is a sample image of the smb.conf configuration file.

[0036] Figure 5 This is a flowchart of the CIFS client's authentication login process through the Samba gateway.

[0037] Figure 6 This is a schematic diagram of the virtual directory hierarchy in an embodiment of the present invention.

[0038] Figure 7 This is a file gateway architecture diagram based on virtual directory extended attributes in an embodiment of the present invention.

[0039] Figure 8 This is a flowchart of the user authentication process in an embodiment of the present invention.

[0040] Figure 9 This is a flowchart of the file gateway permission control process in an embodiment of the present invention. Detailed Implementation

[0041] The embodiments of the present invention will be described in detail below. It should be emphasized that the following description is merely exemplary and is not intended to limit the scope and application of the present invention.

[0042] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of the present invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0043] This invention aims to solve the problems of difficult multi-node configuration synchronization and high resource consumption of multi-process Samba gateways. It proposes a user authentication and file sharing method based on virtual directories and file extended attributes. By obtaining configuration and authentication information through extended attributes, the method avoids multi-server synchronization problems and realizes client aggregation of gateway sub-processes, thereby improving resource utilization and simplifying the gateway architecture process.

[0044] See Figures 6 to 9 This invention provides a user authentication and file sharing method based on a virtual directory, comprising the following steps:

[0045] Connect to the backend storage via the FUSE gateway and generate a virtual directory structure that combines usernames and shared buckets;

[0046] The file gateway obtains all shared mount information and user authentication information through the extended attributes of virtual directories;

[0047] After receiving a user's mount request, the file gateway generates a specific key by combining the user's account information, obtains the user's account authentication information through the extended attributes of the virtual directory, and performs user identity verification based on the authentication information.

[0048] After user authentication is successful, the file gateway queries the shared bucket information that the user needs to access based on the obtained shared mount information and the user's mount request.

[0049] The file gateway obtains the mount information of the shared bucket by utilizing the extended attributes of the virtual directory, determines the final access path, and completes file sharing and permission verification.

[0050] It is worth noting that for object storage, user sharing is typically configured at the bucket level; for file systems, sharing is typically configured at the level of a single file system or file directory. In this invention, object buckets are presented as a single file system within a file system, thereby achieving a unified level of sharing granularity.

[0051] In some embodiments, generating the virtual directory structure combining usernames and shared buckets includes: constructing the virtual directory structure during FUSE process initialization, wherein the first-level directory is the user directory corresponding to the username, and the second-level directory is the bucket directory named after the shared bucket that the user has access to (its hierarchical structure is as follows). Figure 6 As shown in the figure), the permission attributes of the bucket directory are dynamically set based on the access permissions of its corresponding user: if the shared bucket is read-only for the user, the permission attributes of the bucket directory are set to read-only mode; if it is read-write, it is set to read-write mode; when the user calls the get attribute operation, a background IO operation is triggered to refresh the permission attributes of the bucket directory to ensure that they are consistent with the user's current permissions.

[0052] In some embodiments, the dynamic setting of the permission attributes of the bucket directory specifically includes: the permission attribute of the directory corresponding to the read-only mode is to allow only reading and execution, and the permission attribute of the directory corresponding to the read-write mode is to allow reading, writing and execution; the background IO operation is triggered by the user calling the attribute acquisition operation to ensure that the permissions displayed in the virtual directory are synchronized in real time with the user's actual access permissions to the shared bucket in the backend storage.

[0053] In some embodiments, obtaining all shared mount information through the extended attributes of virtual directories includes: the file gateway obtaining a list of all shared buckets presented as shared directories by querying the extended attributes corresponding to predefined global shared information keys; for each shared bucket in the list, the file gateway querying the extended attributes by combining the shared bucket name with a specific key to obtain detailed mount information for that specific shared bucket. The file gateway architecture is as follows... Figure 7 As shown.

[0054] In some embodiments, obtaining and verifying user account authentication information through the extended attributes of the virtual directory includes: the file gateway generating a user authentication information key based on the username by combining the user account information, and obtaining the password or encrypted authentication information of the corresponding user from the virtual directory through the key; the file gateway matching and verifying the obtained authentication information with the authentication information submitted in the user request to complete user authentication.

[0055] In some embodiments, see Figure 8 The user identity verification process specifically includes: the file gateway subprocess obtains the authentication information of the corresponding user by using the extended attributes of the root directory and a key generated based on the username; extracts the key from the obtained user information and performs hash encryption; matches the encryption result with the password string given in the user request, and if the match is successful, the authentication is successful, and the user identification information is summarized; if the match fails or the corresponding user information is not found, the authentication fails.

[0056] In some embodiments, determining the final access path includes: the file gateway combining user account information, the shared bucket information that the user needs to access, and the mount path of the virtual directory to generate a complete local access path; the file gateway searches for the concatenated path in the virtual directory structure, and if the path exists, it confirms successful mounting and allows access; if the path does not exist, it prompts the user that the mounting failed.

[0057] In some embodiments, the method further includes an access control step based on permission attributes: before processing each user's IO operation request, the file gateway needs to obtain the permission attributes of the shared directory corresponding to the target shared bucket for permission checking; if the IO operation request is a write request, it checks whether the permission attributes include write permissions; if not, the request is rejected; to reduce the operation delay caused by permission checks, the file gateway process caches the permission attributes of the shared directory and sets a periodic attribute refresh interval. The control flow is shown in Figure 9.

[0058] In some embodiments, the method further includes: the file gateway obtains configuration and authentication information by querying the extended attributes of the virtual directory, instead of reading the local configuration file, thereby avoiding configuration file synchronization between multiple gateway server nodes; and the FUSE gateway aggregates access to the backend storage, enabling multiple file gateway subprocesses to share the same FUSE process and its storage client connection, thereby improving the reuse efficiency of memory resources.

[0059] The user authentication and file sharing method based on virtual directories proposed in this invention has the following main technical advantages: Through the innovative design of virtual directories combined with file extended attributes, it effectively solves the pain points of existing technologies. On the one hand, it directly obtains configuration and authentication information using extended attributes, without relying on local configuration files, thus completely avoiding the configuration synchronization problem between multiple gateway servers. On the other hand, it uses virtual directories to achieve client aggregation of each gateway subprocess, significantly reducing memory and CPU resource consumption in multi-user scenarios and improving resource utilization. At the same time, this design also simplifies the authentication and sharing process and architecture of file gateways, eliminating the need for direct connection to backend storage or frequent configuration modifications, ultimately significantly improving overall performance.

[0060] The features, working principle and advantages of specific embodiments of the present invention are further described below.

[0061] A method for user authentication and file sharing based on virtual directories is proposed, enabling file sharing and user permission verification based on virtual directories. The method mainly includes: 1) Connecting to backend storage via a FUSE gateway and generating a virtual directory combining username and shared bucket. 2) The file gateway, using a specific key and the extended attributes of the virtual directory, obtains all shared mount information. 3) Upon receiving a user's mount request, the file gateway generates a specific key based on the user's account information and obtains the user's account authentication information through the file's extended attributes, then verifies the authentication information. 4) After successful account authentication, the file gateway uses the obtained shared mount information and the user's mount request to query the shared bucket information that the user needs to access. 5) The file gateway uses the shared bucket information and the extended attributes of the virtual directory to obtain the mount information of that bucket and determine the final access path. Furthermore, based on different users' access permissions to buckets, bucket directories under different user directories have different directory permission attributes.

[0062] Virtual directories based on user and shared directory information:

[0063] like Figure 6 As shown, during Fuse process initialization, a hierarchical directory structure is built, consisting of username + shared bucket / shared directory. If a user has created a shared bucket / directory, a corresponding user directory rgw_user is created in the first-level directory. Under this user directory, a corresponding second-level directory named bucket_directory is created.

[0064] One point that needs special explanation here is that the mode attribute of the shared directory is meaningful. The virtual root directory layer will display the mode attribute of the bucket directory / shared directory based on the current rgw_user's (parent directory, the directory created based on the username) access permissions.

[0065] If this bucket is read-only for the current rgw_user, then the directory's mode attribute will be set to "r-xr-xr-x", which is the read-only attribute and 0555.

[0066] If this bucket is read-write for the current rgw_user, then the directory's mode attribute will be set to "rwxrwxrwx", which is 0777.

[0067] To ensure that the bucket directory attributes are updated promptly after rgw_user access permissions are changed, an I / O operation is initiated in the background to refresh the bucket directory attributes each time the user calls getattr to obtain the mode.

[0068] In addition, virtual directories support obtaining relevant information through extended attributes, avoiding the need to modify configuration files and directly connect to backend storage, thus simplifying the gateway architecture and processing flow.

[0069] Extended attributes based on virtual directories:

[0070] Extended attribute information of virtual directories, such as Figure 7 As shown. By extending the attributes of the virtual directory, various authentication and permission information can be obtained, thus avoiding the file gateway from verifying information by reading the configuration file, and thereby avoiding the configuration file synchronization problem;

[0071] If the key of the directory extended attribute is "bfs_vx.user.+username", the content of the extended attribute obtained is the user's password and other authentication information. After the Samba master process receives the user's mount request, it will combine the username with the extended attribute of the virtual root directory (key is "bfs_vx.user.+username") to obtain the corresponding user's authentication information, and verify it in conjunction with the information in the request.

[0072] If the key corresponding to the directory extended attribute is "bfs_vx.exports", the content of the extended attribute obtained is all the shared directory / bucket information;

[0073] If the key corresponding to the extended attribute is "bfs_vx.share.+bucket name", the content of the extended attribute obtained is the mounting information of that bucket.

[0074] The following is an example of a file gateway authentication and sharing process based on a virtual root directory:

[0075] 1. During Fuse process initialization, user information and bucket sharing information are obtained, and a virtual hierarchical directory is constructed using the username and shared bucket.

[0076] 2. The Samba main process initializes by obtaining all shared directory / bucket information through the extended attributes of virtual directories. First, it obtains all shared bucket information through the "bfs_vx.exports" extension, and then obtains the share name and mount information of each shared bucket through "bfs_vx.share.+bucket name". After receiving a connection request from a new user, the Samba process creates a corresponding child process to serve the logged-in user.

[0077] 3. After receiving a connection request from a new user, the Samba process creates a corresponding child process to serve the logged-in user;

[0078] 4. The Samba child process retrieves the password information of the corresponding user through the extended attributes of the root directory and performs authentication verification in conjunction with the information in the request. The key of the extended attribute is "bfs_vx.user.+username", and the value of the extended attribute is the user's account / authentication information;

[0079] 5. After successful authentication, the Samba child process locates the corresponding shared bucket / shared directory using the user's mount path information, and confirms the final access path by combining the user's account information and shared bucket information. Finally, it replies to the user with a successful mount response. After successful mount, the Samba child process reads and writes data through the mounted directory and responds to the user's read and write requests.

[0080] 6. After successful mounting, the Samba child processes read and write data through the mounted directory and respond to user read and write requests.

[0081] User authentication process:

[0082] User authentication process as follows Figure 8 As shown, the authentication module (bfsauth) uses username / password to match accounts and verify identity.

[0083] Because the password provided by the client is encrypted and cannot be reverse-engineered, the bfs_fuse_daemon process cannot verify its validity. Only the file gateway (Samba) can obtain the password and encrypt it for verification. When a non-object storage user attempts to log in, if the authentication rules fail to find a matching username or the corresponding password does not match, the user's login will be denied.

[0084] User mounting process:

[0085] When processing a mount request, the file gateway combines account information, shared directory information, and the mount path of the virtual directory to obtain a local path.

[0086] For example, if the mount path of the virtual directory is / var / lib / sdsbfs / cifs / mnt and the shared directory is bucket_name, then the file gateway will obtain the mount path / var / lib / sdsbfs / cifs / mnt / rgw_user_name / bucket_name.

[0087] Since the bfs_fuse_daemon process only displays user-accessible bucket / shared directories, if the path can be found, it is assumed that the file gateway can access the files in this directory; otherwise, the file gateway will prompt that the mount failed (path does not exist).

[0088] Access control:

[0089] Control process such as Figure 9 As shown, the file gateway implements access control by verifying the permission attributes of the shared directory. Therefore, a permission check must be performed on the shared directory's attributes before each I / O operation.

[0090] The bfs_fuse_daemon process caches the permission attributes of shared directories and sets a refresh interval to reduce the latency caused by performing permission checks before each operation.

[0091] In summary, this invention proposes a user authentication and file sharing method based on a virtual directory. Compared with existing technologies, the significant technical advantages of this invention include: (1) utilizing the extended attributes of the virtual directory to obtain configuration information and authentication information, avoiding information synchronization problems between multiple servers. (2) through the virtual directory, client aggregation between gateway subprocesses is achieved, improving resource utilization. In general, the method of this invention simplifies the authentication and sharing process of the file gateway through the combination of virtual directory and file directory extended attributes, avoids configuration file synchronization problems, improves memory reuse efficiency through resource sharing, and thus improves overall operating performance.

[0092] This invention also provides a storage medium for storing a computer program, which, when executed, performs at least the methods described above.

[0093] This invention also provides a control device, including a processor and a storage medium for storing a computer program; wherein the processor executes the computer program by performing at least the method described above.

[0094] This invention also provides a processor that executes a computer program, at least performing the methods described above.

[0095] The storage medium can be implemented by any type of non-volatile storage device, or a combination thereof. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc or CD-ROM; magnetic surface memory can be disk storage or magnetic tape storage. The storage media described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable types of memory.

[0096] In the several embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0097] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0098] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0099] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] Alternatively, if the integrated units of this invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0101] The methods disclosed in the several method embodiments provided by this invention can be arbitrarily combined without conflict to obtain new method embodiments.

[0102] The features disclosed in the several product embodiments provided by this invention can be arbitrarily combined without conflict to obtain new product embodiments.

[0103] The features disclosed in the several method or device embodiments provided by the present invention can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0104] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various equivalent substitutions or obvious modifications can be made without departing from the concept of the present invention, and all such modifications, achieving the same performance or application, should be considered within the scope of protection of the present invention.

Claims

1. A method of user authentication and file sharing based on a virtual directory, characterized by, Comprise: Connect the backend storage through the FUSE gateway, and generate a virtual directory structure combined with the username and shared bucket; The file gateway obtains all shared mounting information and user authentication information through the extended attribute of the virtual directory; After receiving the user mounting request, the file gateway generates a specific key combined with the user account information, obtains the user account authentication information through the extended attribute of the virtual directory, and performs user identity verification based on the authentication information; After the user authentication passes, the file gateway queries the shared bucket information that the user needs to access according to the obtained shared mounting information and user mounting request; The file gateway obtains the mounting information of the shared bucket through the extended attribute of the virtual directory based on the shared bucket information, determines the final access path, and completes the file sharing and permission verification.

2. The method of claim 1, wherein, The generation of the virtual directory structure combined with the username and the shared bucket comprises: When the FUSE process is initialized, the virtual directory structure is constructed, wherein the first-level directory is the user directory corresponding to the username, and the second-level directory is the bucket directory named after the shared bucket that the user has access to; The permission attribute of the bucket directory is dynamically set based on the access permission of the corresponding user: if the shared bucket is read-only for the user, the permission attribute of the bucket directory is set to read-only mode; if it is read-write, it is set to read-write mode; When the user calls the get attribute operation, a background IO operation is triggered to refresh the permission attribute of the bucket directory, ensuring that it is consistent with the current user permission.

3. The method of claim 2, wherein, The dynamic setting of the permission attribute of the bucket directory specifically comprises: The read-only mode corresponds to the directory permission attribute of only allowing reading and executing, and the read-write mode corresponds to the directory permission attribute of allowing reading, writing and executing; The background IO operation is triggered by the user calling the get attribute operation, which is used to ensure that the permission displayed in the virtual directory is real-time synchronized with the actual access permission of the user to the shared bucket in the backend storage.

4. The method of claim 1, wherein, The obtaining of all shared mounting information through the extended attribute of the virtual directory comprises: The file gateway obtains the list information of all shared buckets presented in the form of shared directories by querying the extended attribute corresponding to the pre-defined global shared information key; For each shared bucket in the list, the file gateway obtains the detailed mounting information of the shared bucket by querying the extended attribute through a specific key generated based on the shared bucket name.

5. The method of claim 1, wherein, The obtaining of user account authentication information through the extended attribute of the virtual directory and the verification thereof comprise: The file gateway generates a user authentication information key based on the username by combining the user account information, and obtains the password or encrypted authentication information of the corresponding user from the virtual directory through the key; The file gateway matches and verifies the obtained authentication information with the authentication information submitted in the user request to complete the user identity verification.

6. The method of claim 1 or 5, wherein, The user identity verification process specifically comprises: The file gateway child process obtains the authentication information of the corresponding user through the extended attribute of the root directory using the key generated based on the username; The key is extracted from the obtained user information and is hashed encrypted; The encrypted result is matched with the password string given in the user request, and if the matching is successful, the authentication is passed and the user identification information is summarized; if the matching fails or the corresponding user information is not found, the authentication fails.

7. The method of claim 1, wherein, The determination of the final access path comprises: The file gateway combines user account information, shared bucket information that the user needs to access, and a mounting path of the virtual directory to splice a complete local access path; The file gateway searches for the spliced path in the virtual directory structure. If the path exists, it confirms that the mounting is successful and allows access. If the path does not exist, it prompts the user that the mounting fails.

8. The method of claim 1, wherein, It also includes an access control step based on permission attributes: Before processing each IO operation request of the user, the file gateway needs to obtain the permission attributes of the shared directory corresponding to the target shared bucket to perform permission checking; If the IO operation request is a write request, it is checked whether the permission attributes contain write permissions. If not, the request is denied. To reduce the operation delay caused by permission checking, the file gateway process caches the permission attributes of the shared directory and sets a regular attribute refresh interval.

9. The method of claim 1, wherein, It also includes: The file gateway obtains configuration and authentication information by querying the extended attribute set of the virtual directory, instead of reading local configuration files, thereby avoiding configuration file synchronization between multiple gateway server nodes; Through the FUSE gateway aggregation of access to the back-end storage, multiple file gateway subprocesses can share the same FUSE process and its storage client connection, improving the reuse efficiency of memory resources.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method of any one of claims 1 to 9.

Images