Method, device and storage medium for permission control of device node

Abstract

The application relates to the technical field of system security, and discloses a device node permission control method and device, equipment and a storage medium, the method comprises the following steps: obtaining device information of at least one device node; the device information comprises a device category and a device identifier belonging to the device category; providing a configuration interface for a device administrator, and obtaining a permission rule issued by the device administrator through the configuration interface; the permission rule comprises a permission relationship between the device category and a user identifier and between the device identifier and the user identifier; in the case that a first user requests to operate a target device node, the target device category, the target device identifier and the identifier of the first user are compared with the permission rule to determine whether the first user has the permission to operate the target device node. The application can solve the problem of excessive root permission, can finely configure the operation of the device node, and achieves the effect of simplifying the operation of the device administrator.

Description

Technical Field

[0001] This invention relates to the field of system security technology, and in particular to a method, apparatus, device, and storage medium for access control of device nodes. Background Technology

[0002] With the development of computer technology, the processing power of computers and the supported devices and communication methods have increased significantly. More and more intelligent devices can be connected to computers. Although these devices bring convenience, they also increase the complexity of the system and potential security risks. As a result, the security technology of operating systems is receiving more and more attention.

[0003] Traditional Discretionary Access Control (DAC) relies on user groups and file attributes for control. However, root privileges are too broad. If a malicious process illegally obtains root privileges, it can arbitrarily manipulate device nodes and gain access to all permissions and data within the computer. Furthermore, DAC access control cannot provide fine-grained control over device nodes such as Input / Output Control Layers (IOCTLs).

[0004] To address the aforementioned issues, relevant access control schemes can solve some problems by using Mandatory Access Control (MAC) based on security control policies to achieve fine-grained control over device nodes. However, their configuration is overly cumbersome, and for hardware devices, access control can only be implemented through device classification, rather than directly targeting specific device nodes corresponding to device identifiers. For ordinary users, these access control schemes require creating a custom security class for each device node that needs control, and then adding the corresponding device node file to the custom security class, making the process cumbersome. Summary of the Invention

[0005] In view of this, the present invention provides a method, apparatus, device and storage medium for controlling device node permissions, so as to solve the problem of being unable to finely control device node permissions and the operation being cumbersome.

[0006] In a first aspect, the present invention provides a method for access control of device nodes, the method comprising:

[0007] Obtain device information for at least one device node; the device information for at least some of the device nodes includes: device category and device identifier belonging to the device category;

[0008] Provide a configuration interface for device administrators to obtain permission rules issued by the device administrators through the configuration interface; the permission rules include the permission relationship between the device category and the user identifier and the permission relationship between the device identifier and the user identifier;

[0009] When a first user requests to operate a target device node, the target device node's target device category, target device identifier, and the first user's identifier are compared with the permission rules to determine whether the first user has permission to operate the target device node.

[0010] In some optional implementations, the method further includes:

[0011] Construct a data structure for storing the permission rules; the data structure includes a first structure corresponding to the device category and a second structure corresponding to the device identifier;

[0012] Determine whether the device node has a device identifier;

[0013] If the device node has a device identifier, then the device identifier and / or the corresponding device category of the device node are stored in the corresponding structure of the data structure;

[0014] If the device node does not have a device identifier, then the interface index of the device node is used as the device identifier, and the interface index of the device node and / or the corresponding device category are stored in the corresponding structure of the data structure.

[0015] In some optional implementations, the permission rules include:

[0016] The permission relationship between the device category and the second user;

[0017] Alternatively, if there is no permission relationship between the device category and the second user, the permission relationship between the device identifier belonging to the device category and the second user can be determined.

[0018] In some optional implementations, the comparison of the target device classification, target device identifier, and first user identifier with the permission rules based on the target device node includes:

[0019] Search the target device category and target device identifier of the target device node in the permission rules;

[0020] Determine whether there is a permission relationship between the user identifier and the target device category based on the permission rules;

[0021] If there is an authorization relationship between the user identifier and the target device category, then it is determined that the first user has the authorization to operate the target device node;

[0022] If there is no permission relationship between the user identifier and the target device category, then determine whether there is a permission relationship between the user identifier and the target device identifier according to the permission rules;

[0023] If there is an access permission relationship between the user identifier and the target device identifier, then it is determined that the first user has permission to access the target device node;

[0024] If there is no permission relationship between the user identifier and the target device identifier, then it is determined that the first user does not have permission to access the target device node.

[0025] In some optional implementations, the permission rules are stored in a data structure; the data structure includes a first structure for classifying storage devices and a second structure for identifying storage devices.

[0026] The step of searching for the target device category and target device identifier of the target device node in the permission rules includes:

[0027] Traverse the first structure to find the target device category of the target device node;

[0028] The target device identifier of the target device node is located in the second structure under the target device category.

[0029] In some optional implementations, providing a configuration interface for the device administrator and obtaining the permission rules issued by the device administrator through the configuration interface includes:

[0030] Receive the first command from the device administrator based on the operating system, and directly issue the permission rules corresponding to the first command through the configuration interface;

[0031] or,

[0032] Obtain the second command used by the device administrator based on the operating system, load the permission rule configuration file according to the second command; read the permission rules stored in the permission rule configuration file, and issue the permission rules through the configuration interface; the permission rule configuration file is a configuration file in which the device administrator saves the permission rules through the configuration interface.

[0033] In some optional implementations, the method further includes:

[0034] During the multi-user initialization phase of a computer, server, or composite device, the root user's operating system privileges are released and the operating system privileges are assigned to the device administrator.

[0035] After the computer, server, or composite device completes initialization, the device administrator with operating system privileges is allowed to add or disable device nodes; the device administrator with operating system privileges is also allowed to enable or disable the root user's operating system privileges.

[0036] Secondly, the present invention provides a device for controlling access permissions to a device node, the device comprising:

[0037] An acquisition module is used to acquire device information of at least one device node; the device information of at least some of the device nodes includes: device category and device identifier belonging to the device category;

[0038] The configuration module is used to provide a configuration interface for the device administrator to obtain the permission rules issued by the device administrator through the configuration interface; the permission rules include the permission relationship between the device category and the user identifier and the permission relationship between the device identifier and the user identifier;

[0039] The comparison module is used to compare the target device node's target device classification, target device identifier, and the first user's identifier with the permission rules when the first user requests to operate the target device node, in order to determine whether the first user has permission to operate the target device node.

[0040] Thirdly, the present invention provides an electronic device comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the access control method of the first aspect or any corresponding embodiment thereof.

[0041] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer, server, or composite device to perform the access control method described in the first aspect or any corresponding embodiment thereof.

[0042] This invention provides a device node access control method. Each device node has a device category and a device identifier. Device administrators configure access rules related to the device category and device identifier. When a user requests to operate on a target device node, the system compares the access relationships between the current user and the target device node's device category and device identifier within the configured access rules. This achieves fine-grained access control for device node operations and solves the problem of excessive root privileges. Furthermore, a device administrator configuration interface is provided to facilitate access control configuration, simplifying administrator operations and the distribution of access rules. Attached Figure Description

[0043] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating a device node access control method according to an embodiment of the present invention;

[0045] Figure 2 This is a flowchart illustrating an access control method for another device node according to an embodiment of the present invention;

[0046] Figure 3 This is a flowchart illustrating a method for controlling access to another device node according to an embodiment of the present invention.

[0047] Figure 4 This is a diagram of the device node access control architecture according to an embodiment of the present invention;

[0048] Figure 5 This is a structural block diagram of a device node access control device according to an embodiment of the present invention;

[0049] Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] According to an embodiment of the present invention, an embodiment of a device node access control method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer, server or composite device such as a set of executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0052] This embodiment provides a method for controlling access to device nodes, which can be used in the aforementioned computer, server, or composite device. Figure 1 This is a flowchart of a device node access control method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps S101 to S103.

[0053] Step S101: Obtain device information for at least one device node; the device information for at least some device nodes includes: device category and device identifier belonging to the device category.

[0054] A device node is an abstract representation of a hardware device in an operating system (such as Linux / Unix systems), and it typically exists as a file in the / dev directory. For example, keyboard input corresponds to / dev / input / eventX. "At least some device nodes" refers to some or all device nodes.

[0055] Device classification can be a unique number used in the operating system (such as Linux / Unix system) to identify the type of device node. The kernel assigns the unique number corresponding to the device classification to different hardware device types (such as hard drives, USB devices, etc.) to associate the corresponding drivers.

[0056] The supported device categories in this embodiment are shown in Table 1 below.

[0057]

[0058] Table 1

[0059] Device identifiers refer to identifiers in the operating system's device management, used to distinguish different physical devices or device instances under the same driver (i.e., different physical devices or device instances under the same device category).

[0060] When a computer, server, or composite device with one or more physical devices or device entities starts up for the first time, or when a new physical device or device entity is connected during operation, this step S101 is executed to obtain the device classification and device identifier of the physical device or device entity for subsequent permission rule configuration.

[0061] Step S102: Provide a configuration interface for the device administrator and obtain the permission rules issued by the device administrator through the configuration interface; the permission rules include the permission relationship between device category and user and the permission relationship between device identifier and user.

[0062] A device administrator is a specific user who manages devices and user permissions within an operating system. There can be multiple device administrators for the same system.

[0063] The configuration interface refers to the permission rule configuration interface provided in this method, which connects user space and kernel space and transmits the permission rules configured by the device administrator to kernel space.

[0064] For users created on computers, servers, or composite devices, the device administrator can create or modify the permission mapping relationship between the user and the device category and device identifier under the device node. The permission mapping relationship can include: authorized, not authorized, and not configured. Where: authorized means that the user has permission to operate the device node corresponding to the corresponding device category or device identifier; not authorized means that the user does not have permission to operate the corresponding device category or device identifier; not configured means that the device administrator has not created a permission mapping relationship between the user and the device node, and it is regarded as not authorized in comparison or verification. For ease of description, the permission mapping relationship is simply referred to as permission relationship. The authorized mapping relationship can be described as authorized relationship, and the unauthorized mapping relationship can be described as unauthorized relationship or no permission relationship.

[0065] When a device administrator needs to create or modify whether a user can operate all device nodes under a certain device category, or needs to create or modify whether a user can operate a certain device node, this step S102 can be executed, that is, the permission rules for creating or modifying user permissions are issued through the configuration interface.

[0066] Step S103: In the case of a first user requesting to operate the target device node, the target device node's target device classification, target device identifier, and the first user's identifier are compared with the permission rules to determine whether the first user has permission to operate the target device node.

[0067] During operating system runtime, a user can initiate a request to operate a specific device node. For ease of description, the user initiating the request will be referred to as the first user, and the device node that the first user is currently requesting to operate on will be referred to as the target device node. The user-requested operation may include, for example, read, write, or IOCTL operations.

[0068] When comparing the target device node's target device category, target device identifier, and the first user's identifier with the permission rules, the target device category, target device identifier, and permission relationships in the permission rules can be compared to determine the user identifier corresponding to the target device category and target device identifier. If the first user's identifier matches the determined user identifier, it can be determined that the first user has permission to operate the target device node. Alternatively, based on the target device category, target device identifier, and first user's identifier, the corresponding relationship in the permission rules can be located. If the relationship indicates permission, it can be determined that the first user has permission to operate the target device node. Conversely, if the relationship indicates no permission or not configured, it can be determined that the first user does not have permission to operate the target device node.

[0069] This embodiment provides a device node access control method. Each device node has a device category and a device identifier. The device administrator configures permission rules related to the device category and device identifier. When a user requests to operate on a target device node, the system compares the current user's permission with the target device node's device category and device identifier within the configured permission rules. This achieves fine-grained permission configuration for device node operations, addressing the issue of excessive root privileges by allowing the device administrator to control user permissions. Simultaneously, a device administrator configuration interface is provided to facilitate permission relationship configuration, simplifying administrator operations and the distribution of permission rules.

[0070] This embodiment provides a method for controlling access to device nodes, which can be used in the aforementioned computer, server, or composite device. Figure 2 This is a flowchart of the comparison method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps S201 to S207.

[0071] Step S201: Construct a data structure for storing permission rules. The data structure includes a first structure corresponding to the device category and a second structure corresponding to the device identifier.

[0072] The first structure refers to the structure for classifying storage devices. The first structure is automatically generated when a computer, server, or composite device is started for the first time. The first structure can be an array, a linked list, or a vector.

[0073] The second structure refers to the structure of the device identifier under the storage device category. Each element in the second structure (i.e., the device category) should have an empty second structure. The second structure is automatically generated when the computer, server or composite device is started for the first time. The second structure can be an array, a linked list or a vector.

[0074] When a computer, server, or composite device with one or more physical devices or device entities is started for the first time, this step S201 can be executed to construct a data structure for storing device classification and device identification in the permission rules, and automatically generate the first structure and the second structure in the data structure.

[0075] Step S202: Determine whether the device node has a device identifier.

[0076] Device nodes can be of various types, such as character device nodes, block device nodes, and network device nodes.

[0077] For character device nodes or block device nodes, the device node has a device identifier, which can be directly stored in the second structure under the corresponding device category.

[0078] For network device nodes, since the device node does not have a device identifier, it is not possible to directly store the device identifier into the second structure.

[0079] When a computer, server, or composite device with one or more physical devices or device entities is started for the first time, a data structure is built based on step S201, and step S202 can be executed; or, when adding a device (e.g., adding a physical device or device entity), step S202 can also be executed to determine whether the device node has a device identifier, in order to prepare for the storage of the device identifier.

[0080] Step S203: If the device node has a device identifier, then store the device identifier and / or the corresponding device category of the device node into the corresponding structure of the data structure.

[0081] When a computer, server, or composite device with one or more physical devices or device entities is started for the first time, the paths in the computer, server, or composite device can be traversed to pre-fill some device categories into the first structure. Similarly, the device node files under the paths in the computer, server, or composite device can be traversed to pre-add device identifiers to the second structure.

[0082] If a device node has a device identifier, when storing the device identifier, first check if the corresponding device category exists in the first structure. If it exists, store the device identifier in the second structure under the device category. That is, at this time, only the device identifier needs to be stored. If it does not exist, add the corresponding device category to the first structure. For example, use the device category number as an element added to the first structure. Then store the device identifier in the second structure under the device category. That is, at this time, both the device category and the device identifier need to be stored.

[0083] When a computer, server, or composite device with one or more physical devices or device entities is started for the first time or a device is added, this step S203 is performed for the device node with a device identifier to store the device node in a data structure so that the device administrator can add or modify its permission relationships.

[0084] Step S204: If the device node does not have a device identifier, then the interface index of the device node is used as the device identifier, and the interface index of the device node and / or the corresponding device category are stored in the corresponding structure of the data structure.

[0085] An interface index is a number assigned to a network device in an operating system. Each network device has a file located in the system path of the operating system, which records a number, and this file is the interface index of the network device.

[0086] If a device node does not have a device identifier, when storing the device identifier, the interface index of the device node is treated as the device identifier. First, it is checked whether the corresponding device category exists in the first structure. If it exists, the device identifier is stored in the second structure under the device category. If it does not exist, the element of the corresponding device category is added to the first structure, and then the device identifier is stored in the second structure under the device category.

[0087] When a computer, server, or composite device with one or more physical devices or device entities is started up for the first time or a device is added, this step S204 is performed for device nodes without device identifiers to store the device nodes in a data structure so that device administrators can add or modify their permission relationships.

[0088] Step S205: Obtain device information for at least one device node; the device information for at least some device nodes includes: device category and device identifier belonging to the device category.

[0089] Please see details Figure 1 Step S101 of the illustrated embodiment will not be described again here.

[0090] Step S206: Provide a configuration interface for the device administrator and obtain the permission rules issued by the device administrator through the configuration interface; the permission rules include the permission relationship between device category and user and the permission relationship between device identifier and user.

[0091] Please see details Figure 1 Step S102 of the illustrated embodiment will not be described again here.

[0092] In some optional implementations, the permission rules include: the permission relationship between the device category and the second user; or, in the case that there is no permission relationship between the device category and the second user, the permission relationship between the device identifier belonging to the device category and the second user.

[0093] Specifically, device administrators can configure corresponding permission relationships for each user to generate permission rules; for ease of distinction, the user targeted in the permission rule configuration stage will be referred to as the second user. The permission relationship between device categories and second users can be configured.

[0094] The permission relationship can be configured to have a permission relationship or not. If it is configured to have a permission relationship, the second user can operate on the device nodes corresponding to all device identifiers in the second structure under the device category.

[0095] Alternatively, the device administrator can configure the permission relationship between the device identifier belonging to the device category and the second user when there is no permission relationship between the device category and the second user.

[0096] Similarly, the permission relationship between the device identifier and the second user can be configured to have a permission relationship or no permission relationship. If it is configured to have a permission relationship, the second user can have a permission relationship with the device identifier corresponding to the target device node, even if there is no permission relationship with the device category corresponding to the target device node, thus granting the second user permission to operate the target device node. Conversely, if it is configured to have no permission relationship, the second user will not have permission to operate the target device node.

[0097] The permission rule configuration scheme provided in this embodiment can configure the permission relationship of a user's corresponding permissions by device category, and can also make exception configurations for the device node corresponding to a device identifier under a device category that does not have a permission relationship for a user. This further improves the convenience for device administrators to perform permission control, enabling device administrators to configure permission relationships by device category or by device node corresponding to a device identifier, thereby improving the efficiency of permission rule configuration and achieving the effect of fine-grained permission control.

[0098] Step S207: In the case of a first user requesting to operate the target device node, the target device node's target device classification, target device identifier, and the first user's identifier are compared with the permission rules to determine whether the first user has permission to operate the target device node.

[0099] Please see details Figure 1 Step S103 of the illustrated embodiment will not be described again here.

[0100] In some optional implementations, step S207, "compare the target device node's target device classification, target device identifier, and the first user's identifier and permission rules", includes steps A1 to A2.

[0101] Step A1: Find the target device category and target device identifier of the target device node in the permission rules.

[0102] When performing permission verification, the device category and device identifier of the target device node are required, i.e., the target device category and the target device identifier. Specifically, when the first user requests to operate on the target device node, the request initiated by the first user includes the first user's user identifier, and may also include information such as the target device identifier, for example, the target device category.

[0103] For the target device category and target device identifier, a search can be performed within the permission rules to determine the element corresponding to the target device category and target device identifier. This element can indicate which user identifiers have permission relationships with the target device category and target device identifier, or whether a user identifier has permission relationships with the target device category and target device identifier.

[0104] When a user initiates a request to operate on the target device node, obtain the user's user identifier and the target device node's target device identifier and device category, and then execute this step A1.

[0105] In some optional implementations, step A1, “finding the target device category and target device identifier of the target device node in the permission rules,” includes steps A11 and A12.

[0106] Step A11: Traverse the first structure and find the target device category of the target device node.

[0107] By searching for the target device category of the target device node in the first structure, the element corresponding to the target device category within the permission rule is determined.

[0108] Step A12: Locate the target device identifier of the target device node in the second structure under the target device category.

[0109] By searching for the target device identifier of the target device node in the second structure under the target device category, the element corresponding to the target device identifier within the permission rule is determined.

[0110] Step A2: Determine whether there is an authorization relationship between the user identifier and the target device category and / or the target device identifier according to the authorization rules.

[0111] Specifically, the system searches for the target device category and target device identifier within the permission rules to determine the corresponding element within the permission rules, and then determines whether the user's user identifier can operate the target device node corresponding to the target device category and target sub-device type based on the corresponding element.

[0112] In some optional implementations, step A2, "determining whether there is an authorization relationship between the user identifier and the target device category according to the authorization rules," includes steps A21 to A24.

[0113] Step A21: If there is an authorization relationship between the user identifier and the target device category, then it is determined that the first user has the authorization to operate the target device node.

[0114] First, it is necessary to compare the identifier of the user currently requesting the operation (such as user ID, username, etc.) with the device category to which the device node belongs to determine whether there is an authorization relationship between the user identifier requesting the operation and the device category.

[0115] If the user ID currently requesting the operation has an authorization relationship with the device category of the target device node, then the user currently requesting the operation is allowed to operate the target device node, that is, they have the authority to operate the target device node.

[0116] Step A22: If there is no permission relationship between the user identifier and the target device category, then determine whether there is a permission relationship between the user identifier and the target device identifier according to the permission rules.

[0117] If the user currently requesting the operation has no permission relationship with the target device node's device category, a second verification is required to compare whether the user currently requesting the operation has the permission relationship to operate on the target device node under the device category.

[0118] Step A23: If there is an authorization relationship between the user identifier and the target device identifier, then it is determined that the first user has the right to access the target device node.

[0119] If the user currently requesting the operation has an authorization relationship with the device identifier of the target device node, then the user currently requesting the operation is allowed to operate the target device node.

[0120] Step A24: If there is no permission relationship between the user identifier and the target device identifier, then it is determined that the first user does not have permission to access the target device node.

[0121] If the user currently requesting the operation does not have a permission relationship with the device identifier of the target device node, the user currently requesting the operation will be denied the operation on the target device node.

[0122] When a user initiates a request and comparison and verification are required, step A2 is executed to determine whether there is a permission relationship between the user identifier and the device identifier according to the permission rules, and to determine whether the user can operate the target device node based on the permission relationship.

[0123] The device node access control method provided in this embodiment can automatically generate data structures for device classification and device identification storage; it processes device nodes without device identification, enabling the method to simultaneously cover device nodes with and without device identification, allowing device administrators to manage character device nodes, block device nodes, and network device nodes on the same platform; device administrators can configure permission relationships for device categories for a user's permissions, and can also configure exceptions for device nodes corresponding to a device identifier under a device category that does not have permission relationships for a user, further improving the convenience of access control for device administrators, allowing them to control device nodes with different permissions. Permission relationships can be configured for device categories or for device nodes corresponding to a specific device identifier. Simultaneously, the system uses device categories, device identifiers, and user identifiers in the data structure for comparison and verification. A secondary data structure quickly locates the target device node, obtains its target device identifier and device category, and uses this information for the permission rule comparison process. After comparison, the system allows or denies the user's operation request. This enables device administrators to configure permission relationships for both device categories and device nodes corresponding to a specific device identifier, simplifying administrator operations, improving the efficiency of permission rule configuration, and achieving refined permission control.

[0124] This embodiment provides a method for access control of device nodes, which can be used in the aforementioned computers, servers, or composite devices. Figure 3 This is a flowchart illustrating how a device administrator issues permission rules through a configuration interface according to an embodiment of the present invention. This method can also be used to allocate operating system permissions and obtain permission rules issued by the device administrator through the configuration interface, such as... Figure 3 As shown, the process includes the following steps S301 to S305.

[0125] Step S301: In the multi-user phase of initializing the computer, server, or composite device, the root user's operating system privileges are released, and the operating system privileges are assigned to the device administrator.

[0126] The initialization multi-user phase refers to the node where computers and other devices are initialized and users need to log in. It is one of the initialization processes that occur when computers and other devices start up.

[0127] Operating system privileges can be one or more privileges within the operating system. These privileges grant the user, root user, or device administrator the authority to configure permission rules and adjust system authentication procedures. For example, in a Linux system, the operating system privileges that need to be assigned are CAP_MKNOD and CAP_FOWNER.

[0128] When the computer initializes, this step S701 needs to be executed to release the root user's operating system privileges and allocate the operating system privileges to the device administrator, so that the administrator can obtain the necessary operating system privileges.

[0129] Step S302: After the computer, server, or composite device completes initialization, allow device administrators with operating system privileges to add or disable device nodes; allow device administrators with operating system privileges to enable or disable root user operating system privileges.

[0130] Once the device administrator has acquired the corresponding operating system privileges, they can execute step S302 to add or disable device nodes, and to enable or disable the root user's operating system privileges. For example, after the computer has completed initialization, the device administrator can re-enable the root user's operating system privileges, allowing the root user to directly operate the device or adjust permission rules.

[0131] Step S303: Obtain device information for at least one device node; the device information for at least some device nodes includes: device category and device identifier belonging to the device category.

[0132] Please see details Figure 1 Step S101 of the illustrated embodiment will not be described again here.

[0133] Step S304: Provide a configuration interface for the device administrator and obtain the permission rules issued by the device administrator through the configuration interface; the permission rules include the permission relationship between device category and user and the permission relationship between device identifier and user.

[0134] Please see details Figure 1 Step S102 of the illustrated embodiment will not be described again here.

[0135] In some optional implementations, step S304, "providing a configuration interface for the device administrator and obtaining the permission rules issued by the device administrator through the configuration interface", may include step B1 or step B2.

[0136] Step B1: Receive the first command from the device administrator based on the operating system, and directly issue the corresponding permission rules for the first command through the configuration interface.

[0137] The first command can be the first command used by the device administrator through typing, copying, etc. The first command can be directly issued by the command configuration interface to the permission rules modified by the device administrator.

[0138] When a device administrator modifies the permission rules and wants the modified rules to take effect immediately, they can execute step B1 and use the first command to directly issue the permission rules through the configuration interface.

[0139] Step B2: Receive the permission rules stored in the permission rule configuration file, which is loaded by the device administrator based on the second command used by the operating system. The permission rule configuration file is one or more permission rule configuration files that the device administrator sends out and saves through the configuration interface.

[0140] The second command can be a command used by the device administrator through typing, copying, etc. The second command can load the permission rules stored in the configuration file.

[0141] The configuration file can be a single file used to store permission rules that have been modified by the device administrator but do not need to take effect immediately. In this case, the device administrator can choose to distribute the modified configuration rules and store them as a configuration file. When the permission rules need to take effect, the second command can be used to load them.

[0142] When a device administrator modifies a permission rule, but does not need the rule to take effect immediately, and wants it to be saved and loaded at a time deemed appropriate by the device administrator, step B2 can be executed to receive the permission rule stored in the permission rule configuration file from the device administrator based on the second command used by the operating system.

[0143] Step S305: If the first user requests to operate the target device node, the target device node's target device classification and target device identifier are compared with the permission rules to determine whether the first user has permission to operate the target device node.

[0144] Please see details Figure 1 Step S103 of the illustrated embodiment will not be described again here.

[0145] The device node permission control method provided in this embodiment solves the problem of excessive root user privileges through the above-mentioned permission allocation method. Malicious files or programs cannot attack the computer through the root user's privileges, thus ensuring system security.

[0146] Meanwhile, the device node permission control method provided in this embodiment can not only support device administrators to modify permission rules in real time, ensuring the timeliness of permission rules, but also reduce the operational difficulty of device administrators and improve the configuration efficiency of device administrator permission relationships by saving permission rules as configuration files and loading them when needed.

[0147] This embodiment provides a method for controlling the permissions of a device node, which achieves permission control through the coordinated operation of user space and kernel space. Figure 4 This is a diagram of a device node access control architecture according to an embodiment of the present invention.

[0148] In the user space, device administrators can manage permissions through device node control functions. Among them, device permission rule configuration is the configuration of permission rules, device permission effective timing configuration allows device administrators to load permission rule configuration files, and other user permission control allows device administrators with operating system privileges to enable or disable root user operating system privileges.

[0149] The bdev_ctl tool serves as the configuration interface, distributing permission rules or permission rules from the loaded permission rule configuration file to the kernel space.

[0150] The kernel space receives permission rules through the sys interface and verifies whether the user issuing the permission rules has the CAP_MKNOD and CAP_FOWNER operating system privileges. If the verification is successful, the permission rules are transmitted to the user permission verification module. When other users request operations on device nodes, the kernel determines the user's operation method and compares it with the permission rules stored in the user permission verification module. The stored permission rules include user permission information, device category information (device classification), network device information (device classification for network devices), and device number (device identifier).

[0151] After successful comparison, the security module can be used to receive the comparison results and register hook functions to control the target device node. The security module can be an integrated security module that integrates the open-source Linux Security Module (LSM) and expands the bus permission control logic.

[0152] This embodiment also provides a device node access control apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0153] This embodiment provides a device node access control device, such as... Figure 5 As shown, it includes:

[0154] The acquisition module 501 is used to acquire device information of at least one device node; the device information of at least some of the device nodes includes: device category and device identifier belonging to the device category;

[0155] Configuration module 502 is used to provide a configuration interface for the device administrator to obtain the permission rules issued by the device administrator through the configuration interface; the permission rules include the permission relationship between the device category and the user identifier and the permission relationship between the device identifier and the user identifier;

[0156] The comparison module 503 is used to compare the target device node's target device classification, target device identifier, and the first user's identifier with the permission rules when the first user requests to operate the target device node, in order to determine whether the first user has permission to operate the target device node.

[0157] In some alternative embodiments, the apparatus further includes a data storage module, which is used for:

[0158] Construct a data structure for storing the permission rules; the data structure includes a first structure corresponding to the device category and a second structure corresponding to the device identifier;

[0159] Determine whether the device node has a device identifier;

[0160] If the device node has a device identifier, then the device identifier and / or the corresponding device category of the device node are stored in the corresponding structure of the data structure;

[0161] If the device node does not have a device identifier, then the interface index of the device node is used as the device identifier, and the interface index of the device node and / or the corresponding device category are stored in the corresponding structure of the data structure.

[0162] In some optional implementations, the permission rules include:

[0163] The permission relationship between the device category and the second user;

[0164] Alternatively, if there is no permission relationship between the device category and the second user, the permission relationship between the device identifier belonging to the device category and the second user can be determined.

[0165] In some optional implementations, the comparison module 503 compares the target device node's target device classification, target device identifier, and the first user's identifier with the permission rules, including:

[0166] Search the target device category and target device identifier of the target device node in the permission rules;

[0167] Determine whether there is a permission relationship between the user identifier and the target device category based on the permission rules;

[0168] If there is an authorization relationship between the user identifier and the target device category, then it is determined that the first user has the authorization to operate the target device node;

[0169] If there is no permission relationship between the user identifier and the target device category, then determine whether there is a permission relationship between the user identifier and the target device identifier according to the permission rules;

[0170] If there is an access permission relationship between the user identifier and the target device identifier, then it is determined that the first user has permission to access the target device node;

[0171] If there is no permission relationship between the user identifier and the target device identifier, then it is determined that the first user does not have permission to access the target device node.

[0172] The comparison module 503 includes:

[0173] The search unit is used to search for the target device category and target device identifier of the target device node in the permission rules;

[0174] The judgment unit is used to determine, according to the permission rules, whether there is a permission relationship between the user identifier and the target device category;

[0175] If there is an authorization relationship between the user identifier and the target device category, then it is determined that the first user has the authorization to operate the target device node;

[0176] If there is no permission relationship between the user identifier and the target device category, then determine whether there is a permission relationship between the user identifier and the target device identifier according to the permission rules;

[0177] If there is an access permission relationship between the user identifier and the target device identifier, then it is determined that the first user has permission to access the target device node;

[0178] If there is no permission relationship between the user identifier and the target device identifier, then it is determined that the first user does not have permission to access the target device node.

[0179] In some optional implementations, the permission rules are stored in a data structure; the data structure includes a first structure for classifying storage devices and a second structure for identifying storage devices.

[0180] The search unit includes:

[0181] The device classification lookup subunit is used to traverse the first structure and find the target device classification of the target device node.

[0182] The device identifier lookup subunit is used to look up the target device identifier of the target device node in the second structure under the target device category.

[0183] In some optional implementations, the configuration module 502 is used to:

[0184] Receive the first command from the device administrator based on the operating system, and directly issue the permission rules corresponding to the first command through the configuration interface;

[0185] or,

[0186] Obtain the second command used by the device administrator based on the operating system, load the permission rule configuration file according to the second command; read the permission rules stored in the permission rule configuration file, and issue the permission rules through the configuration interface; the permission rule configuration file is a configuration file in which the device administrator saves the permission rules through the configuration interface.

[0187] In some optional embodiments, the apparatus further includes: a system power allocation module, which is used for:

[0188] During the multi-user initialization phase of a computer, server, or composite device, the root user's operating system privileges are released and the operating system privileges are assigned to the device administrator.

[0189] After the computer, server, or composite device completes initialization, the device administrator with operating system privileges is allowed to add or disable device nodes; the device administrator with operating system privileges is also allowed to enable or disable the root user's operating system privileges.

[0190] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0191] This invention also provides an electronic device having the above-described features. Figure 5 The access control device for the shown device node. Please refer to [link / reference]. Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention, such as... Figure 6As shown, the electronic device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.

[0192] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0193] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0194] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0195] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0196] The electronic device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 40 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0197] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touch screen.

[0198] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0199] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0200] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for access control of device nodes, characterized in that, The method includes: Obtain device information for at least one device node; the device information for at least some of the device nodes includes: device category and device identifier belonging to the device category; A configuration interface is provided for the device administrator to obtain the permission rules issued by the device administrator through the configuration interface; the permission rules include the permission relationship between the device category and the second user; or, if there is no permission relationship between the device category and the second user, the permission relationship between the device identifier belonging to the device category and the second user; When a first user requests to operate a target device node, the target device node's target device category, target device identifier, and the first user's identifier are compared with the permission rules to determine whether the first user has permission to operate the target device node. The step of comparing the target device classification, target device identifier, and first user identifier of the target device node with the permission rules includes: Search the target device category and target device identifier of the target device node in the permission rules; Determine whether there is a permission relationship between the user identifier and the target device category based on the permission rules; If there is an authorization relationship between the user identifier and the target device category, then it is determined that the first user has the authorization to operate the target device node; If there is no permission relationship between the user identifier and the target device category, then determine whether there is a permission relationship between the user identifier and the target device identifier according to the permission rules; If there is an access permission relationship between the user identifier and the target device identifier, then it is determined that the first user has permission to access the target device node; If there is no permission relationship between the user identifier and the target device identifier, then it is determined that the first user does not have permission to access the target device node; The method further includes: Construct a data structure for storing the permission rules; the data structure includes a first structure corresponding to the device category and a second structure corresponding to the device identifier; Determine whether the device node has a device identifier; If the device node has a device identifier, then the device identifier and / or the corresponding device category of the device node are stored in the corresponding structure of the data structure; If the device node does not have a device identifier, then the interface index of the device node is used as the device identifier, and the interface index of the device node and / or the corresponding device category are stored in the corresponding structure of the data structure.

2. The method according to claim 1, characterized in that, The permission rules are stored in a data structure; the data structure includes a first structure for classifying storage devices and a second structure for identifying storage devices; The step of searching for the target device category and target device identifier of the target device node in the permission rules includes: Traverse the first structure to find the target device category of the target device node; The target device identifier of the target device node is located in the second structure under the target device category.

3. The method according to claim 1, characterized in that, The provision of a configuration interface for the device administrator, and the acquisition of permission rules issued by the device administrator through the configuration interface, include: Receive the first command from the device administrator based on the operating system, and directly issue the permission rules corresponding to the first command through the configuration interface; or, Obtain the second command used by the device administrator based on the operating system, load the permission rule configuration file according to the second command; read the permission rules stored in the permission rule configuration file, and issue the permission rules through the configuration interface; the permission rule configuration file is a configuration file in which the device administrator saves the permission rules through the configuration interface.

4. The method according to claim 1, characterized in that, The method further includes: During the multi-user initialization phase of a computer, server, or composite device, the root user's operating system privileges are released and the operating system privileges are assigned to the device administrator. After the computer, server, or composite device completes initialization, the device administrator with operating system privileges is allowed to add or disable device nodes; the device administrator with operating system privileges is also allowed to enable or disable the root user's operating system privileges.

5. A device for controlling access permissions to a device node, characterized in that, The device includes: An acquisition module is used to acquire device information of at least one device node; the device information of at least some of the device nodes includes: device category and device identifier belonging to the device category; The configuration module is used to provide a configuration interface for the device administrator to obtain the permission rules issued by the device administrator through the configuration interface; the permission rules include the permission relationship between the device category and the second user; or, if there is no permission relationship between the device category and the second user, the permission relationship between the device identifier belonging to the device category and the second user; The comparison module is used to compare the target device node's target device classification, target device identifier, and the first user's identifier with the permission rules when the first user requests to operate the target device node, in order to determine whether the first user has permission to operate the target device node. The comparison module includes: The search unit is used to search for the target device category and target device identifier of the target device node in the permission rules; The judgment unit is used to determine, according to the permission rules, whether there is a permission relationship between the user identifier and the target device category; If there is an authorization relationship between the user identifier and the target device category, then it is determined that the first user has the authorization to operate the target device node; If there is no permission relationship between the user identifier and the target device category, then determine whether there is a permission relationship between the user identifier and the target device identifier according to the permission rules; If there is an access permission relationship between the user identifier and the target device identifier, then it is determined that the first user has permission to access the target device node; The device further includes: a data storage module, which is used for: Construct a data structure for storing the permission rules; the data structure includes a first structure corresponding to the device category and a second structure corresponding to the device identifier; Determine whether the device node has a device identifier; If the device node has a device identifier, then the device identifier and / or the corresponding device category of the device node are stored in the corresponding structure of the data structure; If the device node does not have a device identifier, then the interface index of the device node is used as the device identifier, and the interface index of the device node and / or the corresponding device category are stored in the corresponding structure of the data structure.

6. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the access control method for the device node according to any one of claims 1 to 4 by executing the computer instructions.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer, server, or composite device to execute the access control method for the device node according to any one of claims 1 to 4.

Images