Access control method, system and home smart gateway

Abstract

This embodiment provides an access control method, system, and home smart gateway. The method includes: starting multiple independent smbd processes; starting the corresponding wsdd2 process for each smbd process; responding to a device query request from the network neighbor page, obtaining the IP address returned by one of the wsdd2 processes based on the username matching the user's own username. The network neighbor page includes device controls corresponding to multiple wsdd2 processes, and the device query request is generated after any device control is triggered, including the username; generating a login interface based on the IP address using the file sharing service provided by the corresponding smbd process; responding to the received login information, performing login verification based on a password file, and entering the shared path after successful verification. This embodiment solves the technical problem of data isolation during cloud drive sharing.

Description

Technical Field

[0001] This disclosure relates to the field of network neighbor technology, and in particular to an access control method, system, and home smart gateway. Background Technology

[0002] The Network Neighborhood feature provided by the Windows operating system is a common way to access shared resources on a local area network (LAN). Through the Network Neighborhood interface, accessible devices within the LAN are displayed. Clicking a device icon allows users to access the file-sharing directory provided by that device. Based on the cloud storage directory mapping technology within the Network Neighborhood feature, a communication connection can be established between a remote cloud storage server and a local device, such as a home smart gateway. This allows Windows-based terminal devices within the LAN of the home smart gateway to display the corresponding cloud storage device icon in the Network Neighborhood interface, and users can access files on the cloud storage server by clicking the device icon.

[0003] In a local area network (LAN) environment, when multiple users need to share the same cloud drive, the relevant technology achieves this by creating multiple subdirectories corresponding to different accounts under the root directory of the cloud drive, allowing different users to access their own subdirectories. However, this method cannot prevent users from accessing other users' subdirectories, and therefore cannot achieve effective data isolation. Summary of the Invention

[0004] To address the data isolation issue in shared cloud storage, this embodiment provides an access control method, system, and home smart gateway.

[0005] In some embodiments, an access control method is provided, the access control method comprising: Multiple independent smbd processes are started. Each smbd process provides file sharing services for the corresponding username by loading its own configuration file. Each smbd process is pre-configured with an independent running directory and configuration file. The username, IP address, sharing path and password file corresponding to different configuration files are all different. Start the corresponding wsdd2 process for each smbd process. Each wsdd2 process provides network neighbor service for different usernames through different main functions. In the main function of each wsdd2 process, the username corresponding to the network neighbor service is different, and the IP address corresponding to the username is configured to the IP address corresponding to the username in the configuration file. In response to a device query request from the Network Neighborhood page, obtain the IP address returned by one of the wsdd2 processes based on the username being the same as its own. The Network Neighborhood page includes device controls corresponding to multiple wsdd2 processes. The device query request is generated after any device control is triggered. The device query request includes the username. Based on the IP address, a login interface is generated using the file sharing service provided by the corresponding smbd process. In response to the received login information, the system performs login verification based on the password file, and enters the shared path after successful verification.

[0006] One of the above technical solutions has the following advantages or beneficial effects: This embodiment of the present disclosure provides independent file sharing and network neighbor services to different users by starting multiple independent smbd processes and corresponding wsdd2 processes. Each process achieves user isolation through independent configuration files, running directories, and password files, ensuring that different users can only access their own dedicated shared paths, and that each smbd process can run stably and independently. Simultaneously, when responding to a device query request, the wsdd2 process returns an IP address matching the current username, thereby guiding the terminal device to connect to the corresponding smbd process. Compared with the prior art, this embodiment of the present disclosure effectively prevents users from accessing other users' shared paths when multiple users share the same cloud drive in the same local area network environment; furthermore, it directly displays the device controls corresponding to each user on the network neighbor page, improving the ease of operation and intuitive isolation when users share the cloud drive.

[0007] In some embodiments, an access control method is provided, wherein the main function of the wsdd2 process includes a first variable, a second variable, and an input parameter processing function, the first variable being used for the IP address of the storage device discovery service, and the second variable being used for the username of the storage device discovery service; the wsdd2 process corresponding to each smbd process is started respectively, including: Multiple wsdd2 processes are started by using multiple startup commands containing different values. In each wsdd2 process, the IP address corresponding to the first variable is set to the IP address in the value information, and the username corresponding to the second variable is set to the username in the value information, through the input parameter processing function.

[0008] One of the above technical solutions has the following advantages or beneficial effects: by setting different IP addresses and usernames in the startup command, each wsdd2 process can independently bind to the corresponding network neighbor service after startup. At the same time, by adopting this method of passing in the value information, it is not necessary to hardcode these configuration information in the code in advance, thereby improving the flexibility and maintainability of the system.

[0009] In some embodiments, an access control method is provided in which the main function of the wsdd2 process includes an IP address reply function, which is configured to return the IP address in the first variable as a response result to the query requester.

[0010] One of the above technical solutions has the following advantages or beneficial effects: by binding the IP address reply function to the first variable, the wsdd2 process can return the IP address corresponding to the process when it receives a device query request, thereby ensuring that the terminal device connects to the correct smbd process.

[0011] In some embodiments, an access control method is provided, which starts multiple independent smbd processes respectively, and further includes: adding the IP address in the value information to the bridge interface of the gateway by using an IP address addition command, and binding each IP address to a unique smbd process.

[0012] One of the above technical solutions has the following advantages or beneficial effects: by pre-adding each IP address to the bridging interface of the gateway and binding it to a unique smbd process, it ensures that each smbd process has an independent network identifier, thereby achieving user isolation at the network layer. No additional network configuration is required when starting the smbd process, ensuring the speed and simplicity of the process startup process.

[0013] In some embodiments, an access control method is provided, which involves starting multiple independent smbd processes, and further includes: Register an account on the cloud storage server and create multiple subdirectories under the root directory of the account; In response to a sub-account creation request, create the sub-account; Obtain the configuration file corresponding to the smbd process of the sub-account. Configure the username, IP address, shared path, and password file in the configuration file. The shared path corresponds to a unique subdirectory.

[0014] One of the above technical solutions has the following advantages or beneficial effects: by completing account registration and subdirectory creation on the cloud disk server in advance, and configuring an independent smbd process and its exclusive configuration file for each sub-account, each sub-account has an independent shared path and access permissions. Thus, without the cloud disk side being aware of the existence of the sub-accounts, user isolation can be completed solely through the smbd process on the gateway side, thereby avoiding an increase in the management complexity of the cloud disk server.

[0015] In some embodiments, an access control method is provided, which, after obtaining the configuration file corresponding to the smbd process, further includes: configuring the access permissions of the subdirectory in the configuration file to the username corresponding to the sub-account.

[0016] One of the above technical solutions has the following advantages or beneficial effects: by explicitly specifying in the configuration file that the access permissions of the subdirectory correspond only to the username of the sub-account, it further ensures that only the sub-account can access its exclusive shared path, thereby improving the data isolation effect.

[0017] In some embodiments, an access control method is provided, which, after obtaining the configuration file corresponding to the smbd process, further includes configuring an independent log storage path and an independent running directory for the smbd process in the configuration file.

[0018] One of the above technical solutions has the following advantages or beneficial effects: by configuring an independent log storage path and running directory for each smbd process, the running status of each process and the log recording do not interfere with each other, which facilitates the independent and stable operation of each process and improves the maintainability and security of the system.

[0019] In some embodiments, an access control method is provided, wherein the main function of the wsdd2 process includes a third variable, which is used for the workgroup of the storage device discovery service; and the wsdd2 process corresponding to each smbd process is started respectively, including: The wsdd2 process is started multiple times by using multiple startup commands containing different values. In the corresponding wsdd2 process, the working group corresponding to the third variable is set to the working group in the value information through the input parameter processing function.

[0020] One of the above technical solutions has the following advantages or beneficial effects: by passing different workgroup value information to each wsdd2 process, each process can independently respond to device discovery requests from different workgroups, thereby achieving precise device discovery and access control.

[0021] In some embodiments, an access control system is provided, the system comprising: The terminal device, equipped with a Windows operating system, is used to initiate device query requests and input login information; A home smart gateway, which is on the same local area network as the terminal device, is used to execute the access control method in the above embodiments. The cloud storage server can connect to a home smart gateway to respond to access requests for shared paths and return the data in the shared path.

[0022] One of the above technical solutions has the following advantages or beneficial effects: This embodiment of the present disclosure provides independent file sharing and network neighbor services to different users by starting multiple independent smbd processes and corresponding wsdd2 processes. Each process achieves user isolation through independent configuration files, running directories, and password files, ensuring that different users can only access their own dedicated shared paths, and that each smbd process can run stably and independently. Simultaneously, when responding to a device query request, the wsdd2 process returns an IP address matching the current username, thereby guiding the terminal device to connect to the corresponding smbd process. Compared with the prior art, this embodiment of the present disclosure effectively prevents users from accessing other users' shared paths when multiple users share the same cloud drive in the same local area network environment; furthermore, it directly displays the device controls corresponding to each user on the network neighbor page, improving the ease of operation and intuitive isolation when users share the cloud drive.

[0023] In some embodiments, a home smart gateway is provided, the gateway comprising: The communication interface enables communication and connection with terminal devices and cloud storage servers. The processor, connected to the communication interface, is used to execute the access control method in the above embodiments.

[0024] One of the above technical solutions has the following advantages or beneficial effects: This embodiment of the present disclosure provides independent file sharing and network neighbor services to different users by starting multiple independent smbd processes and corresponding wsdd2 processes. Each process achieves user isolation through independent configuration files, running directories, and password files, ensuring that different users can only access their own dedicated shared paths, and that each smbd process can run stably and independently. Simultaneously, when responding to a device query request, the wsdd2 process returns an IP address matching the current username, thereby guiding the terminal device to connect to the corresponding smbd process. Compared with the prior art, this embodiment of the present disclosure effectively prevents users from accessing other users' shared paths when multiple users share the same cloud drive in the same local area network environment; furthermore, it directly displays the device controls corresponding to each user on the network neighbor page, improving the ease of operation and intuitive isolation when users share the cloud drive. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1This is a schematic diagram illustrating a cloud storage access scenario according to some embodiments; Figure 2 This is a flowchart illustrating the preparation phase according to some embodiments; Figure 3 This is a schematic diagram of the sub-account creation process according to some embodiments; Figure 4 This is a schematic diagram of the configuration process for wsdd2 according to some embodiments; Figure 5 This is a flowchart illustrating an access control method according to some embodiments; Figure 6 This is a timing interaction diagram of the cloud disk access process according to some embodiments; Figure 7 This is a schematic diagram of a network neighbor page according to some embodiments. Detailed Implementation

[0027] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this disclosure.

[0028] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0029] To facilitate understanding of the plan, the following explanations are provided for relevant terms: Samba is an open-source software suite that implements the Server Message Block (SMB) and Common Internet File System (CIFS) protocols on Unix-like systems (such as Linux). It allows network services such as file sharing, printer sharing, and user authentication between Unix / Linux hosts and Windows systems, and is a key component for achieving interoperability between different operating systems.

[0030] SMB / CIFS protocol: A core network protocol used for file sharing, printer access, and inter-process communication in Windows network environments. In this embodiment, Samba implements this protocol, enabling embedded devices to be recognized and accessed by the Windows system.

[0031] Network Neighborhood / Network Discovery: A graphical browsing feature provided by the Windows operating system for accessing shared network resources. It relies on protocols such as Network Basic Input / Output System (NetBIOS) names, Link-Local Multicast Name Resolution (LLMNR), and Web Services Dynamic Discovery (WS-Discovery) to discover other computers and services on the network.

[0032] NetBIOS name: A 16-byte name used to uniquely identify a device or service on a network, displayed as "computer name" in Windows Network Neighborhood.

[0033] LLMNR: Link-Local Multicast Name Resolution Protocol. When DNS resolution fails, a host can resolve the names of neighboring hosts through multicast queries within the local link scope. Windows systems widely use LLMNR for local network discovery.

[0034] WS-Discovery: A network service discovery protocol based on the Simple Object Access Protocol (SOAP). Wsdd2 is an open-source daemon that implements the WS-Discovery protocol and is commonly used to make non-Windows devices (such as Linux devices running Samba) appear in Windows Network Neighborhood.

[0035] Samba3 and Samba4: These are the main version branches of the Samba project. Samba3 has a relatively simple architecture, focusing on file and print sharing with low resource consumption, and is widely deployed on resource-constrained devices such as gateways. Samba4, on the other hand, introduces full Active Directory domain controller functionality, providing powerful centralized user and policy management capabilities, but its system complexity and resource consumption (especially memory and storage) increase significantly.

[0036] Multi-tenancy: A software architecture technique that enables a single software instance to serve multiple users or "tenants" while ensuring that each tenant's data, configuration, and user management are isolated from each other.

[0037] It should be noted that this disclosure uses a home scenario as an example, but the technical solution of this disclosure is not limited to the home scenario. It can also be applied to file sharing scenarios within enterprise LANs or other file sharing scenarios that require multi-tenant isolation. Cloud storage sharing is a file sharing method. In scenarios other than the home scenario, the home smart gateway can be replaced by a corresponding gateway device.

[0038] Figure 1 This is a schematic diagram illustrating a cloud storage access scenario according to some embodiments. For example... Figure 1 As shown, this scenario includes a home smart gateway, a cloud storage server, and terminal devices. The home smart gateway (hereinafter referred to as the gateway), as the core access and forwarding device within the local area network (LAN), maps the remote cloud storage server to a virtual shared device within the LAN that can be directly accessed by the terminal devices. The cloud storage server is located on the public network side, providing users with remote, high-capacity storage resources. Terminal devices (such as personal computers running Windows operating systems, hereinafter referred to as user PCs) access the LAN built by the gateway via wired or wireless means. In the network neighbor interface provided by the terminal device's operating system (such as Windows' "Network" or "Network Neighborhood"), they can discover and access the virtual shared device presented by the gateway, thereby using the remote storage resources provided by the cloud storage server in a local LAN access manner.

[0039] To present virtual shared devices and provide file sharing capabilities on the terminal device side, two types of basic services need to be deployed on the gateway: one is the Samba service, which provides file sharing services based on the SMB / CIFS protocol; the other is the WS-Discovery / LLMNR discovery service (hereinafter referred to as wsdd2 service), which responds to network neighbor discovery requests initiated by the terminal device, so that the virtual shared devices represented by the Samba service can be displayed by the terminal device in the network neighbor interface.

[0040] In some embodiments, considering the strict limitations on CPU processing power, memory capacity, and Flash storage space of embedded devices such as gateways and routers, this disclosure selects the resource-efficient Samba3 version as the basic implementation of the file sharing service, rather than the more complex and resource-intensive Samba4 version. The Samba3 service provides file sharing services through the smbd process; the wsdd2 service provides network neighbor services, such as device discovery and name resolution, through the wsdd2 process.

[0041] However, the native Samba3 single-instance deployment solution only supports a single configuration file, a single password file, and a single sharing context, which cannot achieve data isolation between users in a multi-user shared cloud drive scenario. That is, any user can access other users' cloud drive directories through the same Samba service, which poses a security risk of unauthorized data access.

[0042] To address this issue, this disclosure proposes an access control method that provides multi-user access control through collaborative isolation at the process, network, and storage layers. This method achieves access control by starting independent smbd and wsdd2 processes for each authorized user within a home smart gateway. Specifically, the smbd and wsdd2 processes belonging to the same user must be pre-bound based on network identifiers such as IP address, NetBIOS name (which is the username), and workgroup. Furthermore, each smbd process is pre-configured with its own configuration file, password file, and running directory. Based on this configuration, complete independence is achieved at the user level, encompassing process lifecycle, network identification, authentication, logging, and shared paths. This achieves data isolation for multi-user management without requiring an upgrade to Samba4 or significantly increasing hardware resource overhead.

[0043] In some embodiments, the access control method provided in this disclosure can be divided into a preparation phase and an execution phase. The preparation phase involves configuring the smbd and wsdd2 processes in the gateway before starting them, so that the subsequently started smbd and wsdd2 processes can meet the access control requirements of this disclosure. The process of the preparation phase can be found in [reference needed]. Figure 2 For the execution phase process, please refer to [link / reference]. Figure 5 .

[0044] Figure 2 This is a flowchart illustrating the preparation phase according to some embodiments, such as Figure 2 As shown, the preparation phase may include the following steps: Step S101: Configure the smbd process.

[0045] In some embodiments, configuring the smbd process includes configuring the smbd process's configuration files. Each configuration file corresponds to a single user and is generated after the sub-account is created. The gateway's operating system (referred to as the system) generates an independent smbd configuration file for each user after the sub-account is created (e.g., smb_1.conf, smb_2.conf...smb_N.conf, where N is a sequence number, and different sequence numbers correspond to different users). Each smbd process loads its own configuration file at startup using the "-s" command-line parameter; different processes load different configuration files. Each configuration file differentiates its configuration on key network and identity parameters, thereby uniquely binding the process to a specific user.

[0046] Before creating a sub-account, you need to register an account with the cloud storage server, i.e., register a cloud storage account. You can register a cloud storage account on the gateway's cloud storage management page. After the account is successfully created, you can access the storage space of that account on the cloud storage server from the gateway's cloud storage management page. At this point, the storage space corresponds to the root directory of the cloud storage.

[0047] To meet the access needs of multiple users to the cloud drive, multiple subdirectories can be created in the root directory, with each subdirectory used by one user.

[0048] After creating the subdirectories of the cloud drive, you can continue to create sub-accounts, each corresponding to one user. Sub-accounts are relative to the gateway side; the cloud drive side is unaware of their existence.

[0049] The cloud storage management page also includes a sub-account creation control. When a user clicks this control, the terminal generates a sub-account creation request, and in response, creates the sub-account. The sub-account creation process can be found in [link to documentation]. Figure 3 .

[0050] Figure 3 This is a schematic diagram of a sub-account creation process according to some embodiments, such as Figure 3 As shown, creating a sub-account may include the following steps: Step S201: Enter the sub-account creation page.

[0051] In some embodiments, the sub-account creation page can be accessed from the gateway's cloud storage management page.

[0052] Step S202: Configure network information.

[0053] In some embodiments, network information is used to limit the scope of device query requests responded to by the smbd process. Specifically, network configuration information may include: The username field (i.e., the netBIOS name field) specifies the NetBIOS name (i.e., the computer name / device name displayed in Network Neighborhood, or the username of the corresponding sub-account) corresponding to the request responded to by this smbd process. The netBIOS name field values ​​are different for different smbd processes. For example, the first user might be "admin1", the second user might be "admin2", and so on, so that each user appears as an independent virtual computer in Network Neighborhood.

[0054] The IP address field (i.e., the interfaces field) specifies the IP address that the smbd process listens for and responds to SMB connection requests to. To achieve strong isolation at the network layer, this embodiment pre-selects several IP addresses not occupied by physical devices from the local area network segment (e.g., 192.168.x.211, 192.168.x.212, ... within the 192.168.x.0 / 24 segment). These IP addresses are then added as secondary IP addresses (virtual IP addresses) to the gateway's bridging interface (e.g., br0) using an IP address addition command (e.g., the "ip addr add" command). Each secondary IP address is assigned to a separate smbd process and bound by the interfaces field. Thus, different smbd processes listen for different IP addresses, and each IP address is bound to a unique smbd process.

[0055] By pre-adding virtual IP addresses to the gateway's bridging interface using the IP address addition command and binding each IP address to a unique smbd process, each smbd process is ensured to have an independent network identifier, thereby achieving user isolation at the network layer. No additional network configuration is required when starting the smbd process, ensuring the speed and simplicity of the process startup process.

[0056] The workgroup field specifies the name of the Windows workgroup to which the smbd process belongs. Different smbd processes can be configured with different workgroups (e.g., WORKGROUP_1, WORKGROUP_2, ...), further enhancing the differentiation at the network neighbor level.

[0057] Step S203: Configure the password file.

[0058] In some embodiments, each configuration file includes a password file field (i.e., the smb passwd file field), which points to a password file belonging only to the corresponding user (e.g., smbpasswd_1, smbpasswd_2, ...). Each password file stores only the user's own account and Samba encrypted password, and does not contain any other users' credentials. The smbd process only reads its own password file during login authentication, thereby achieving physical isolation of identity credentials and avoiding the risk of all user credentials being leaked if a single password file is compromised.

[0059] Step S204: Configure the shared path.

[0060] In some embodiments, each configuration file defines the cloud drive mount path accessible to the corresponding user through a shared section. Specifically, each configuration file's shared section contains a path field, whose value points to the local mount directory of the cloud drive uniquely corresponding to that user, for example: / tmp / mnt / cloud / {phone number} / {sharepath} or / tmp / mnt / cloud / {phone number}{sharepath}, where sharepath is the shared subpath configured by the user in the management interface. If the path starts with ' / ', it is concatenated directly; otherwise, ' / ' is added as a separator. The shared path corresponds to a unique subdirectory in the cloud drive, and the phone number is the phone number used when registering the cloud drive account. Thus, the file system root directories served by different smbd processes do not overlap, achieving physical isolation of user data at the storage path level.

[0061] By pre-registering accounts and creating subdirectories under the root directory on the cloud storage server, and configuring an independent smbd process and its dedicated configuration file for each sub-account, the configuration file can be configured with the username, IP address, shared path, and password file. The shared path corresponds to a unique subdirectory in the cloud storage, so that each sub-account has an independent shared path and access permissions. Thus, user isolation can be achieved solely through the smbd process on the gateway side without the cloud storage side being aware of the existence of the sub-accounts, avoiding an increase in the management complexity of the cloud storage server.

[0062] Step S205: Configure access permissions.

[0063] In some embodiments, within the shared section of each configuration file, the `valid users` field (i.e., the access permission field) explicitly restricts access to the shared path to only the corresponding single user (e.g., admin1, admin2, ..., i.e., the usernames of the corresponding sub-accounts). Simultaneously, the following settings are configured: `browseable=yes`, `public=no`, `guest ok=no`, and `guest account=root`, to disable anonymous and guest access and enforce authentication. Combined with the aforementioned independent password file, this strictly ensures that user 1 can only access shared path 1 through smbd process 1, and cannot browse or read / write any files under shared path 2, achieving strong isolation at the permission level.

[0064] By explicitly configuring the access permissions (valid users field) of the subdirectory to the username corresponding to the sub-account in the configuration file, it is further ensured that only the sub-account can access its exclusive shared path, thereby further improving the data isolation effect.

[0065] In some embodiments, to ensure the independent and stable operation of each smbd process, an independent log storage path can be configured for each smbd process in the configuration file. Specifically, the configuration file may include a log file field to specify the storage path for a dedicated log file (e.g., / var / log / samba / log_1.smbd, / var / log / samba / log_2.smbd, ...). Connection logs, access logs, error logs, etc., generated by each smbd process during operation are written independently to their respective log files. This facilitates troubleshooting and auditing at the user level and avoids content mixing and lock contention issues caused by multiple processes concurrently writing to the same log file.

[0066] In some embodiments, to ensure the independent and stable operation of each smbd process, an independent running directory can be configured for each smbd process.

[0067] To avoid conflicts between multiple smbd processes during operation due to shared runtime resources such as lock files, PID files, and cache files, this embodiment of the disclosure synchronously creates an independent runtime directory structure for each smbd process when creating users and corresponding configuration files, including but not limited to: / var / lib / sambaN / private: This is used to store the private data of this instance (such as secrets.tdb, encryption keys, etc.). / var / lib / sambaN / lock: This file stores the lock files for this instance. / var / lib / sambaN / statedir: The directory used to store the state information of this instance; / var / lib / sambaN / cache: Used to store the cached data of this instance; / var / run / sambaN: This is used to store the PID file and runtime socket for this instance.

[0068] The sequence number N corresponds to different users and distinguishes different smbd processes; it is not a Samba version number. Each configuration file points to these dedicated directories through fields such as private dir, lock directory, statedir directory, cache directory, and piddirectory.

[0069] By configuring an independent log storage path and an independent running directory for each smbd process, the running status of each process and the log recording do not interfere with each other, which facilitates the independent and stable operation of each smbd process and improves the maintainability and security of the system.

[0070] In some embodiments, to facilitate the management of the smbd process, the configuration file of the smbd process can be managed through a preset database, and operations such as starting and ending the smbd process can be controlled.

[0071] When a user adds a sub-account through the gateway management page, the system dynamically generates the aforementioned exclusive smb_{index}.conf configuration file and smbpasswd_{index} password file according to the user information and serial number index recorded in the database and the template configuration file. When a user is deleted or disabled, the system synchronously deletes or disables the corresponding configuration file and terminates the relevant process.

[0072] By centrally managing the database instead of directly writing to the system startup script (such as rcS), flexible creation, destruction, and status query of multi-user instances are achieved, avoiding the maintainability issues caused by hard-coding user information in the static startup script.

[0073] In other embodiments, the startup commands for each smbd process can be directly written into the system startup script, thereby enabling the smbd processes to start quickly after the gateway powers on or the system restarts.

[0074] The following section describes the deployment of multiple wsdd2 process instances.

[0075] Step S102: Configure the wsdd2 process.

[0076] In some embodiments, to meet the technical requirement that multiple wsdd2 processes announce different virtual IP addresses to network neighbors and bind to corresponding smbd processes, this disclosure embodiment makes a series of configurations to the source code of the wsdd2 process. The main function of the wsdd2 process adds and configures a first variable, a second variable, a third variable, an input parameter processing function, and an IP address reply function. The first variable is used for the IP address bound to the storage device discovery service (i.e., the wsdd2 service); the second variable is used for the username (i.e., the NetBIOS name) corresponding to the storage device discovery service; and the third variable is used for the workgroup to which the storage device discovery service belongs.

[0077] Figure 4 This is a schematic diagram illustrating the configuration process of wsdd2 according to some embodiments, such as Figure 4 As shown, the configuration process may include the following steps: Step S301: Create IP address variables.

[0078] In some embodiments, a new global variable `configured_ip` is added to the wsdd2 source code. This is the first variable (i.e., the IP address variable), initially set to NULL. It is used to store the virtual IP address declared to the terminal device by the user via command-line parameters during the execution of the wsdd2 process; that is, the IP address of the virtual device. For the terminal device, the devices corresponding to the cloud drives displayed on the Network Neighborhood page are virtual devices, not actual physical devices existing within the local area network.

[0079] Step S302: Configure input parameter options.

[0080] In some embodiments, the "i:" option is set in the string of the getopt option (input parameter option) of the main function of the wsdd2 process to pass the IP address to the first variable; at the same time, the "-N" option is reserved for passing the second variable (NetBIOS name) and the "-G" option is reserved for passing the third variable (workgroup name).

[0081] Step S303: Configure the input parameter processing function.

[0082] In some embodiments, an example of a startup command for the wsdd2 process is: / sbin / wsdd2 -i br0:192.168.21.211 -N admin1 -G WORKGROUP_1 Among them, the input parameter option corresponding to "-i br0:192.168.21.211" is the "i:" option, which is used to pass the IP address to the first variable; "-N admin1" is used to pass the username to the second variable; and "-G WORKGROUP_1" is used to pass the workgroup name to the third variable.

[0083] To parse the above options, the input parameter processing function of the main function is configured with processing logic for the "i:", "-N", and "-G" options. The processing logic for the "i:" option includes: splitting the parameter into an interface name part and an IP address part using ':' as the separator; if the parameter does not contain ':', or the interface name part exceeds 16 bytes (IFNAMSIZ limit), or the IP address part is invalid, the help function is called and an error is reported before exiting; otherwise, the interface name part is copied to the ifname variable (used to specify the listening network card, e.g., br0), and the IP address part is copied to the first variable, configured_ip (for subsequent declaration). The processing logic for the "-N" option includes copying the parameter value to the second variable, netbiosname; the processing logic for the "-G" option includes copying the parameter value to the workgroup variable, i.e., the third variable.

[0084] Using the aforementioned parameter processing function, the gateway can launch multiple wsdd2 processes using startup commands containing different values ​​(i.e., different IP addresses, usernames, and workgroup values). Within each wsdd2 process, the IP address (first variable), username (second variable), and workgroup (third variable) are set to their respective values ​​from the input parameter information. Since each wsdd2 process runs in an independent process address space, by passing different -i, -N, and -G parameter values ​​to different processes in the startup command, each process can externally declare a different virtual IP address, a different NetBIOS name, and a different workgroup.

[0085] By setting different IP addresses, usernames, and workgroups in the startup command, each wsdd2 process can independently bind to the corresponding network neighbor service after startup. At the same time, this method of passing in the value information eliminates the need to hardcode these configuration information in the code in advance, thereby improving the system's flexibility and maintainability.

[0086] Furthermore, by passing different workgroup values ​​to a third variable for each wsdd2 process, each process can independently respond to device discovery requests from different workgroups, thus achieving precise device discovery and access control.

[0087] Step S304: Configure the IP address reply function.

[0088] In some embodiments, when the wsdd2 process responds to an LLMNR / WS-Discovery query, it needs to return the IP address of the device represented by this service to the querying party. This disclosure embodiment configures the IP address response function, such as the connected_if function which selects the response address based on the source address of the received packet, to return the IP address in the first variable as the response result to the query requester.

[0089] In practice, the `wsd_recv_action` function, which is used to generate the reply message in the `wsdd2` process, can call the `connected_if` function and pass in the `configured_ip` of the current process. This allows the IP address in `configured_ip` to be returned as a response result to the query requester.

[0090] By binding the IP address reply function to the first variable, the wsdd2 process can return the IP address corresponding to the process when it receives a device query request, thereby ensuring that the terminal device can connect to the correct smbd process.

[0091] With the above configuration, the gateway only needs to deploy one executable program for the wsdd2 process to start multiple wsdd2 process instances simultaneously by passing different -i, -N, and -G parameter values ​​in the startup command. In some embodiments, the startup command for the wsdd2 process is as follows: / sbin / wsdd2 -i br0:192.168.21.211 -N admin1 -G WORKGROUP_1 / sbin / wsdd2 -i br0:192.168.21.212 -N admin2 -G WORKGROUP_2 Here, " / sbin / wsdd2" is the path to the wsdd2 executable program; "br0:192.168.xx" following "-i" specifies the physical network interface name br0 being listened to and the virtual IP address advertised by the instance, respectively; the string following "-N" is the NetBIOS name of the instance (i.e., the computer name / username displayed in Network Neighborhood); and the string following "-G" is the workgroup name to which the instance belongs. The values ​​of these three types of parameters differ in different wsdd2 processes and are strictly consistent with the values ​​of the interfaces, netbios name, and workgroup fields in the corresponding smbd process configuration file. This establishes a one-to-one binding relationship between the wsdd2 process and the smbd process in terms of IP address, username, and workgroup, ensuring that the IP address returned by Network Neighborhood discovery can be accurately routed to the corresponding smbd listening socket.

[0092] In some embodiments, after configuring the wsdd2 process and the smbd process, multiple independent smbd processes and corresponding wsdd2 processes can be started to enable multi-user access control of the cloud disk.

[0093] Figure 5 This is a flowchart illustrating an access control method according to some embodiments, such as Figure 5 As shown, the method may include the following steps: Step S401: Start multiple independent smbd processes respectively.

[0094] In some embodiments, after receiving a startup command for the file sharing service (e.g., a startup command triggered by system boot, user service activation, or dynamic startup after adding a new user), the gateway's process management module reads all enabled cloud storage user records from a preset database. For each cloud storage user record, a corresponding smbd process is started. Each smbd process loads its own configuration file during startup to provide file sharing services for the corresponding username. Each smbd process has an independent pre-configured running directory and configuration file; the username, IP address, sharing path, and password file are different for each configuration file. The process management module is used to start and stop processes on the gateway.

[0095] After startup, multiple smbd processes exist simultaneously in the gateway. Each process independently listens on an SMB port on a virtual IP, possessing its own file descriptor, authentication context, and log output handle. The processes do not share any user-space data structures, achieving strong process-level isolation. For example, smbd process 1 listens on 192.168.21.211:445, using the smbpasswd_1 password file, serving the / tmp / mnt / cloud / test1 directory; smbd process 2 listens on 192.168.21.212:445, using the smbpasswd_2 password file, serving the / tmp / mnt / cloud / test2 directory, and the two processes do not interfere with each other.

[0096] Step S402: Start the wsdd2 process corresponding to each smbd process respectively.

[0097] In some embodiments, after starting a corresponding smbd process for each user, the process management module then starts a dedicated wsdd2 process for that user. Each wsdd2 process provides network neighbor service (i.e., device discovery service) for a different username through different main functions. In the main functions of each wsdd2 process, the username corresponding to the network neighbor service is different, and the IP address corresponding to the username is configured to the IP address corresponding to the username in the configuration file.

[0098] When each wsdd2 process starts and enters its main function for parameter resolution, the input parameter processing function stores the virtual IP address passed from the command line into the first variable `configured_ip` in the process's address space, the NetBIOS name (username) into the second variable `netbiosname`, and the workgroup into the third variable `workgroup`. The workgroup presented to the outside world by each wsdd2 process is the `WORKGROUP_{index}` passed from its command line, consistent with the corresponding smbd process.

[0099] The above startup process is executed repeatedly, ensuring that the same number of wsdd2 processes as the smbd processes run simultaneously on the gateway. Each wsdd2 process is bound to one smbd process in terms of IP address, NetBIOS name (username), and workgroup. After accessing the Network Neighborhood page through a terminal device, users can see multiple independent virtual computers (i.e., virtual devices). Each virtual computer has its own name, workgroup, and IP address, corresponding to a user's cloud storage space.

[0100] Step S403: Respond to the device query request from the Network Neighborhood page and return the corresponding IP address.

[0101] In some embodiments, after a user opens the Network Neighborhood page on a terminal device, the terminal device sends a multicast query message to the local area network to enumerate available devices. Multiple wsdd2 processes on the gateway each reply with their own NetBIOS name and workgroup. Based on this, the terminal device displays multiple device controls (different device controls are represented by different device icons) on the Network Neighborhood page. Each device control corresponds to a wsdd2 process, and the device control displays the corresponding user's NetBIOS name. When a user clicks on one of the device controls on the Network Neighborhood page, the terminal device generates and sends a device query request to the gateway. This device query request is an LLMNR query message or a WS-Discovery query message, which includes a query name field (i.e., a username field), the value of which is the username corresponding to the device control.

[0102] Upon receiving the query message, each wsdd2 process on the gateway parses the query name field in the message. If the query name does not match the username bound to its own second variable (i.e., the NetBIOS name does not match), the message is discarded without response. If the query name matches the username in its own second variable, the IP address reply function is called to construct a reply message.

[0103] The successfully matched wsdd2 process, following the reply logic, reads the bound virtual IP address (e.g., 192.168.21.211) from its first variable `configured_ip` using the IP address reply function, fills it into the IP address field of the LLMNR reply message or the WS-Discovery ProbeMatch message, and returns this IP address as the response result to the terminal device that initiated the query. Thus, the terminal device obtains the IP address returned by one of the wsdd2 processes based on the username matching its own.

[0104] In some embodiments, the wsdd2 process performs double verification of the NetBIOS name and workgroup before constructing a reply message. The corresponding IP address is only returned when both the NetBIOS name and workgroup match, in order to further reduce the risk of incorrect routing.

[0105] Step S404: Generate a login interface based on the IP address and the file sharing service provided by the corresponding smbd process.

[0106] In some embodiments, the terminal device establishes an SMB connection to the gateway based on the IP address (e.g., 192.168.21.211) obtained in step S403. Since this IP address has been bound to the br0 bridge interface as a secondary IP, and only the corresponding smbd process (e.g., smbd process 1) listens for this IP address through the interfaces field in the configuration file, it can receive the connection request for the SMB connection. Other smbd processes will not receive the connection request because they are not listening for this IP address.

[0107] After smbd process 1 establishes an SMB connection with the terminal device, because its shared segment configuration of public=no and guest ok=no disables anonymous and guest access, it returns login page data to the terminal device through the gateway. The terminal device then displays the login page on its user interface, such as popping up a login dialog box prompting the user to enter login information (such as username and password). Through this IP address-based routing mechanism, when the user clicks different device controls, the terminal device will connect to different smbd processes on different virtual IPs. The login interface presented by each process and the subsequent shared view are also independent of each other, ensuring complete isolation of the access link.

[0108] Step S405: In response to the received login information, perform login verification according to the password file, and enter the shared path after successful verification.

[0109] In some embodiments, after a user enters their username and password in the login dialog box, the terminal device sends the login information to the connected smbd process through the gateway.

[0110] After receiving the login information, the smbd process opens the corresponding password file according to the password file path pointed to by the smb passwd file field in its configuration file (e.g., smbpasswd_1), and then verifies the username and password submitted by the user. Since each password file only stores the credentials of the corresponding user, even if the user enters another user's account and password, no match will be found in the password file, resulting in authentication failure.

[0111] In some embodiments, after both the username and password have been verified, the smbd process further checks whether the authenticated username is in the list of users allowed to access the share, based on the valid users field in the configuration file.

[0112] In some embodiments, after authentication and permission verification are successful, the smbd process accesses the cloud storage server according to the shared path specified in the path field of the configuration file (e.g., / tmp / mnt / cloud / test1), sends an access request to the specified directory to the cloud storage server to obtain the directory data corresponding to the shared path, and then returns the directory data corresponding to the path to the terminal device. The terminal device can then display the directory page in the file explorer, where users can perform operations such as uploading, downloading, creating, deleting, and renaming files.

[0113] In some embodiments, if a user attempts to access another user's virtual device, the access is routed to the smbd process (e.g., smbd process 2) listening on the response IP address. If the user attempts to log in using admin1's credentials, smbd process 2 will authenticate based on smbpasswd_2. Since this file does not contain admin1's credentials, authentication fails. The user cannot access admin2's shared path, nor can they access their own shared path through this login portal, thus further blocking unauthorized cross-user data access at the login portal level.

[0114] This disclosure provides independent file sharing and network neighborhood services to different users by launching multiple independent smbd processes and corresponding wsdd2 processes. Each process uses independent configuration files, running directories, and password files to achieve user isolation, ensuring that different users can only access their dedicated shared paths, and that each smbd process can run stably and independently. Simultaneously, when responding to device query requests, the wsdd2 process returns an IP address matching the current username via an IP address reply function, thereby guiding the terminal device to connect to the corresponding smbd process. Compared to existing technologies, this disclosure effectively prevents users from accessing other users' shared paths when multiple users share the same cloud drive in the same local area network environment; furthermore, it directly displays the device controls corresponding to each user on the network neighborhood page, improving the ease of operation and intuitive isolation when sharing the cloud drive.

[0115] To further describe the access control method disclosed herein, the following section uses a timing interaction diagram of the cloud disk access process as an example.

[0116] Figure 6 For example, a timing interaction diagram of the cloud disk access process according to some embodiments, such as Figure 6 As shown, the cloud disk access process involves interaction between the terminal device, the gateway, and the cloud disk server. The terminal device is located within the local area network of the gateway and interacts with the cloud disk server through the gateway.

[0117] After the gateway starts multiple smbd processes and their corresponding wsdd2 processes, it can provide users with cloud disk access functionality. The following describes the five stages of the three-way interaction in chronological order: Phase 1: Service Launch and Preparation Phase.

[0118] This phase corresponds to steps S401 and S402: The gateway's process management module reads user records from the database in a loop, starting an smbd process and a wsdd2 process bound to each user's three key elements; the smbd process loads a dedicated configuration file using the "-s" parameter and listens for the corresponding virtual IP; the wsdd2 process parses the -i, -N, and -G parameters in the startup command using the input parameter processing function, writing them into the first, second, and third variables respectively. Before or simultaneously with the service startup, the gateway also mounts the corresponding subdirectories of each user in the root directory of the cloud storage server to the shared path pointed to by the path field in the local configuration file, ensuring that the shared path actually exists and is accessible after the smbd process starts.

[0119] Phase Two: Network Neighbor Discovery Phase.

[0120] This phase occurs between steps S402 and S403. After the user accesses the Network Neighborhood page on their terminal device, the terminal device can send multicast query messages, such as WS-Discovery probe messages and LLMNR general query messages, to the gateway to obtain available devices on the network. Each wsdd2 process on the gateway will receive this multicast query message and reply using the LLMNR protocol to return its own device information. The device information includes the NetBIOS name (username) stored in the second variable and the workgroup name stored in the third variable.

[0121] Based on the received device information, the terminal device displays multiple device icons on the Network Neighborhood page. The device icons may display the NetBIOS name; see [link to relevant documentation]. Figure 7 The device icons corresponding to admin1 and admin2 are the NetBIOS names of the virtual devices.

[0122] Figure 7 This is a schematic diagram of a network neighbor interface according to some embodiments. Figure 7 As shown in the embodiments of this disclosure, multiple device icons can be displayed in the network neighbor interface. Each device icon corresponds to a directory of an independent user on the cloud storage server. Users can directly click the corresponding icon in the network neighbor interface to access their exclusive directory without having to share the same device with other users in the network neighbor interface. The isolation effect is more intuitive and the operation path is simpler.

[0123] Phase 3: Device Click and Connection Phase.

[0124] This stage corresponds to step S403. After a user clicks a device icon, the terminal device initiates an LLMNR query message (i.e., a device query request) to the target device, carrying the username of the clicked device. Upon receiving this query message, only the wsdd2 processes on the gateway that match the query name in the second variable return the virtual IP address from the first variable via the IP address reply function; the remaining wsdd2 processes discard the message and do not respond. The terminal device then initiates an SMB connection request to the gateway based on the obtained IP address. The kernel assigns the request to the corresponding smbd process listening on that IP address, completing the SMB protocol negotiation.

[0125] Phase 4: Login authentication phase.

[0126] This stage corresponds to step S404. After the smbd process completes the SMB protocol negotiation with the terminal device, due to the public=no and guest ok=no configuration, it will return a response requiring authentication to the terminal device. Based on this, the terminal device will pop up a login dialog box on the user interface, prompting the user to enter a username and password.

[0127] Based on embodiments of this disclosure, the user in Figure 7 After clicking on their own device icon, a login window pops up. Users can access files in the corresponding shared path by entering their username and password. Other users who click on the device icon and enter their own username and password will not be able to access that user's shared path, nor will they be able to access their own shared path. This embodiment of the disclosure achieves login entry-level isolation by binding a unique account to the login window. Compared to allowing multiple accounts to log in through the same entry point, this further enhances the data isolation effect between different users.

[0128] Phase 5: File Access Phase.

[0129] This stage corresponds to step S405. After the user enters their username and password in the login dialog box, the terminal device sends the login information to the connected smbd process. The smbd process performs identity verification based on the password file pointed to by its own configuration file, and performs permission verification in conjunction with the valid users field. Only after successful verification does the smbd process send an access request to the specified directory to the cloud disk server according to the shared path specified in the path field of the configuration file, that is, to obtain the directory data corresponding to the shared path.

[0130] After receiving the directory data from the cloud storage server, the smbd process sends it back to the terminal device, allowing the terminal device to display the directory page in its file explorer. Therefore, no actual file access interaction occurs between the gateway and the cloud storage server before successful login authentication, fully ensuring the security of cloud storage data access.

[0131] In some embodiments, a home smart gateway (device embodiment) is provided, including a communication interface and a processor: the communication interface is capable of communicating with a terminal device and a cloud disk server; the processor is connected to the communication interface and is used to execute the access control method in any of the above embodiments.

[0132] The aforementioned smart home gateway provides independent file sharing and network neighborhood services to different users by launching multiple independent smbd processes and corresponding wsdd2 processes. Each process uses independent configuration files, running directories, and password files to achieve user isolation, ensuring that different users can only access their own dedicated shared paths, and that each smbd process can run stably and independently. Simultaneously, when responding to device query requests, the wsdd2 process returns an IP address matching the current username, guiding the terminal device to connect to the corresponding smbd process. Compared to existing technologies, this smart home gateway effectively prevents users from accessing other users' shared paths when multiple users share the same cloud drive, and the network neighborhood page directly displays the device controls for each user, improving operational convenience and the intuitiveness of isolation.

[0133] In some embodiments, a home smart gateway is provided, which is located on the same local area network as the terminal device, and is used to execute the access control method in any of the above embodiments.

[0134] In some embodiments, an access control system is provided, the system comprising: The terminal device, equipped with a Windows operating system, is used to initiate device query requests and input login information; A home smart gateway, which is on the same local area network as the terminal device, is used to execute the access control method in any of the above embodiments; The cloud storage server can connect to a home smart gateway to respond to access requests for shared paths and return the data in the shared path.

[0135] The aforementioned access control system provides independent file sharing and network neighborhood services to different users by launching multiple independent smbd processes and corresponding wsdd2 processes within the home smart gateway. Each process uses independent configuration files, runtime directories, and password files to achieve user isolation, ensuring that different users can only access their designated shared paths, and that each smbd process runs stably and independently. Simultaneously, the wsdd2 process returns an IP address matching the current username when responding to device query requests, guiding the terminal device to connect to the corresponding smbd process. Compared to existing technologies, this system effectively prevents users from accessing other users' shared paths when multiple users share the same cloud drive within the same local area network environment. Furthermore, the network neighborhood page directly displays the device controls corresponding to each user, improving the ease of operation and intuitive isolation when sharing the cloud drive.

[0136] Through the embodiments of this disclosure, on resource-constrained embedded gateway / router devices, without upgrading to the resource-intensive Samba4 version, multi-user data isolation capabilities similar to Samba4 AD domains can be achieved simply by using Samba3 multi-process and modifying wsdd2 multi-instance methods, significantly reducing hardware costs.

[0137] By using independent configuration files, independent password files, independent running directories, independent log files, and independent shared paths, a defense-in-depth isolation system is built from four levels: process, network, identity, and storage, avoiding the risks of mixed configurations and unauthorized access in a single-instance multi-user mode.

[0138] By adding the "-i" command-line parameter and the first variable configured_ip to wsdd2, end-to-end collaborative isolation between the network discovery protocol (LLMNR / WS-Discovery) and the file transfer protocol (SMB) is achieved. The IP address returned by the discovery layer corresponds strictly one-to-one with the IP address listened to by the transport layer, thus solving the problems of broadcast response conflicts and addressing ambiguities when multiple instances coexist.

[0139] With a database-driven dynamic configuration generation and process management mechanism, adding, deleting, starting, and stopping users does not require modifying firmware or restarting the service, providing excellent scalability and ease of operation and maintenance.

[0140] In some embodiments, defects in the native netlink message parsing code of wsdd2 are also fixed, such as correcting the ifinfomsg / ifaddrmsg / rtmsg structures, correcting RTA_PAYLOAD, and fixing mixed variable names. This can ensure service stability in scenarios with dynamic addition and deletion of multiple IP addresses and avoid service failure caused by abnormal parsing of interface address events.

[0141] By presenting a separate login entry through an independent device icon in the Network Neighborhood interface, the multi-user isolation experience is further enhanced from the perspectives of visualization and login path, completely eliminating the possibility of cross-account login.

[0142] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this disclosure, and are not intended to limit them. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure.

Claims

1. An access control method, characterized in that, include: Multiple independent smbd processes are started. Each smbd process provides file sharing services for the corresponding username by loading its own configuration file. Each smbd process is pre-configured with an independent running directory and configuration file. The username, IP address, sharing path and password file corresponding to different configuration files are all different. Start the wsdd2 process corresponding to each smbd process respectively. Each wsdd2 process provides network neighbor service for different usernames through different main functions. In the main function of each wsdd2 process, the username corresponding to the network neighbor service is different, and the IP address corresponding to the username is configured to the IP address corresponding to the username in the configuration file. In response to a device query request from the Network Neighborhood page, obtain the IP address returned by one of the wsdd2 processes based on the fact that the username is the same as its own. The Network Neighborhood page includes device controls corresponding to multiple wsdd2 processes. The device query request is generated after any device control is triggered. The device query request includes the username. Based on the IP address, a login interface is generated through the file sharing service provided by the corresponding smbd process. In response to the received login information, login verification is performed according to the password file, and the user is then allowed to enter the shared path after successful verification.

2. The access control method according to claim 1, characterized in that, The main function of the wsdd2 process includes a first variable, a second variable, and an input parameter processing function. The first variable is used to store the IP address of the device discovery service, and the second variable is used to store the username of the device discovery service. Start the corresponding wsdd2 process for each smbd process, including: Multiple wsdd2 processes are started by multiple startup commands containing different value information, so that in the corresponding wsdd2 process, the IP address corresponding to the first variable is set to the IP address in the value information, and the username corresponding to the second variable is set to the username in the value information through the input parameter processing function.

3. The access control method according to claim 2, characterized in that, The main function of the wsdd2 process includes an IP address reply function, which is configured to return the IP address in the first variable as a response result to the query requester.

4. The access control method according to claim 2, characterized in that, Multiple independent smbd processes are started separately. Prior to this, the process also includes adding the IP address from the value information to the bridge interface of the gateway using the IP address addition command, and binding each IP address to a unique smbd process.

5. The access control method according to claim 1, characterized in that, Multiple independent smbd processes are started separately, as previously included: Register an account with the cloud disk server and create multiple subdirectories under the root directory of the account; In response to a sub-account creation request, create the sub-account; Obtain the configuration file of the smbd process corresponding to the sub-account, and configure the username, IP address, shared path and password file in the configuration file, wherein the shared path corresponds to a unique subdirectory.

6. The access control method according to claim 5, characterized in that, After obtaining the configuration file corresponding to the smbd process, the method further includes: configuring the access permissions of the subdirectory in the configuration file to the username corresponding to the sub-account.

7. The access control method according to claim 1, characterized in that, After obtaining the configuration file corresponding to the smbd process, the process further includes configuring an independent log storage path and an independent running directory for the smbd process in the configuration file.

8. The access control method according to claim 2, characterized in that, The main function of the wsdd2 process includes a third variable, which is used to store the workgroup of the device discovery service. Start the corresponding wsdd2 process for each smbd process, including: The wsdd2 process is started multiple times by multiple startup commands containing different value information, so that in the corresponding wsdd2 process, the working group corresponding to the third variable is set to the working group in the value information through the input parameter processing function.

9. An access control system, characterized in that, include: The terminal device, equipped with a Windows operating system, is used to initiate device query requests and input login information; A home smart gateway, located on the same local area network as the terminal device, is used to execute the access control method according to any one of claims 1-8; The cloud storage server can connect to the home smart gateway and, in response to access requests for the shared path, return the data under the shared path.

10. A home smart gateway, characterized in that, include: The communication interface enables communication and connection with terminal devices and cloud storage servers. A processor, connected to the communication interface, is used to execute the access control method according to any one of claims 1-8.

Images