Authority management method and device, electronic equipment, storage medium and program product

Abstract

The application provides a permission management method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of security management. The method comprises the following steps: receiving an API calling request sent by a client, determining a target service accessed based on the API calling request; querying a first permission management attribute of the target service on the server; if the first permission management attribute is not queried, routing the API calling request to the target service; and if the first permission management attribute is queried, performing permission verification on the API calling request of the client. The application only needs to configure the first permission management attribute for the service that needs permission management, thereby reducing the waste of resources and performance and improving the system performance.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of security management and control, and particularly relates to a permission management and control method and device, electronic equipment, a storage medium and a program product. BACKGROUND

[0002] In an operating system, dbus (an inter-process communication mechanism optimized for a desktop environment) provides powerful and flexible cross-process communication functions. For some services involving security, the API provided by the service can only be called by an authorized client, and therefore permission management and control of API call requests is required.

[0003] dbus itself provides a security management and control scheme, which controls the calling of related APIs by clients by setting corresponding service permissions in a configuration file. The configuration file provided by dbus can control whether a user can start a service and whether the user can send a message to the service or an interface under the service. However, the user-mode configuration file can be modified, thereby bypassing the security management and control of service calling and causing certain security risks.

[0004] Currently, in order to prevent the configuration in the configuration file from being modified, dbus further adapts SELinux (Security-Enhanced Linux). By modifying the internal code of dbus, it is supported to control whether the service can be started based on a service name by using SELinux, and it is also supported to control the message sending from process A to process B, so that the permission check is completed in the kernel mode, and the possibility of modification of the user-mode configuration file is also avoided. However, SELinux performs permission management and control based on a whitelist mechanism, and only a client object listed in the whitelist has permission to access, that is, only a terminal that meets the configuration requirements has permission to access. Based on this, all terminals need to be tagged for permission management and control based on the whitelist mechanism, and some terminals do not have permission management and control requirements, thereby causing the introduction of extra tags, and further causing waste of resources and performance and system performance degradation. SUMMARY

[0005] The present application provides a permission management and control method, device, electronic equipment, storage medium and program product, to solve the defect of waste of resources and performance in the prior art, and to realize a high-performance permission management and control mode.

[0006] The present application provides a permission management and control method, applied to a server side, and the method comprises the following steps:

[0007] receiving an API call request sent by a client, and determining a target service accessed based on the API call request;

[0008] query a first permission control attribute of the target service for the client;

[0009] if the first permission control attribute is not queried, route the API call request to the target service;

[0010] if the first permission control attribute is queried, perform permission verification on the API call request of the client.

[0011] According to the permission control method provided by the application, the permission verification on the API call request of the client comprises:

[0012] query a second permission control attribute of the target service for the client;

[0013] if the second permission control attribute is queried, perform permission verification on the API call request based on the first permission control attribute and the second permission control attribute to obtain a permission verification result;

[0014] if the permission verification result is that there is permission, route the API call request to the target service.

[0015] According to the permission control method provided by the application, the query of the second permission control attribute of the target service for the client comprises:

[0016] query the second permission control attribute of the target service for the client based on a first socket sent by the client;

[0017] wherein, the first socket and the second socket of the client itself exist reference, the first socket stores the first permission control attribute, and the second socket stores the second permission control attribute, so that the server can query the second permission control attribute based on the first socket.

[0018] According to the permission control method provided by the application, the first permission control attribute is generated based on the following way:

[0019] obtain an extended attribute configured on a file corresponding to the target service;

[0020] determine a first key of a hash table based on the extended attribute;

[0021] if the first key is found in the hash table based on the first key, determine the position of the first key in the hash table as the first permission control attribute;

[0022] If the first key is not found in the hash table based on the first key, the first key is inserted into the hash table, and an insertion position of the first key in the hash table is determined as the first permission control attribute.

[0023] According to the permission control method provided by the application, the first key of the hash table is determined based on the extended attribute, and the method comprises the following steps:

[0024] The extended attribute is split according to the type to obtain a plurality of attributes.

[0025] The plurality of attributes are respectively taken as the second key of the hash table.

[0026] The hash table is searched based on each second key to determine the target position of each second key in the hash table.

[0027] The first key is determined based on the integer value of each target position.

[0028] The application further provides a permission control method applied to a client, and the method comprises the following steps:

[0029] An API calling request is sent to a server, so that the server performs permission verification on the API calling request.

[0030] The server performs permission verification on the API calling request based on the following method:

[0031] The target service accessed based on the API calling request is determined.

[0032] The first permission control attribute of the target service of the server is queried.

[0033] If the first permission control attribute is not queried, the API calling request is routed to the target service.

[0034] If the first permission control attribute is queried, the API calling request of the client is subjected to permission verification.

[0035] According to the permission control method provided by the application, if the first permission control attribute of the server is queried, the API calling request sent to the server further comprises the following steps:

[0036] The second permission control attribute of the client is sent to the server based on the second Socket of the client itself.

[0037] The second Socket and the first Socket of the server have a reference relationship, the first Socket stores the first permission control attribute, and the second Socket stores the second permission control attribute, so that the client can send the second permission control attribute to the server based on the second Socket.

[0038] The first Socket is created by the client and sent to the server.

[0039] The application further provides a permission control device deployed on a server, and the device comprises:

[0040] A request receiving module is configured to receive an API calling request sent by a client, and determine a target service accessed based on the API calling request.

[0041] An attribute querying module is configured to query a first permission control attribute of the target service of the server.

[0042] A request routing module is configured to route the API calling request to the target service if the first permission control attribute is not queried.

[0043] A permission checking module is configured to perform permission checking on the API calling request of the client if the first permission control attribute is queried.

[0044] The application further provides a permission control device deployed on a client, and the device comprises:

[0045] A request sending module is configured to send an API calling request to a server, so that the server performs permission checking on the API calling request.

[0046] The server performs permission checking on the API calling request in the following manner:

[0047] Determine a target service accessed based on the API calling request.

[0048] Query a first permission control attribute of the target service of the server.

[0049] Route the API calling request to the target service if the first permission control attribute is not queried.

[0050] Perform permission checking on the API calling request of the client if the first permission control attribute is queried.

[0051] The application further provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the permission control method according to any one of the above when executing the program.

[0052] The application further provides a non-transitory computer readable storage medium, which stores a computer program, wherein the computer program is executed by a processor to implement the permission control method according to any one of the above.

[0053] The application further provides a computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the permission control method according to any one of the above.

[0054] The permission control method, device, electronic device, storage medium and program product provided by the application receive an API calling request sent by a client, determine a target service accessed based on the API calling request, query a first permission control attribute of the target service on a server, and route the API calling request to the target service if the first permission control attribute is not queried, so that the API calling request is routed to the target service directly without the first permission control attribute, that is, no permission control is confirmed by default without the first permission control attribute, and the API calling request of the client is verified for permission only if the first permission control attribute is queried, that is, the permission control of the target service on the server is confirmed only if the first permission control attribute is configured, and the API calling request of the client is verified for permission only then, so that all terminals and services do not need to be labeled, and the first permission control attribute only needs to be configured for the services that need permission control, thereby reducing the waste of resources and performance and improving system performance. BRIEF DESCRIPTION OF DRAWINGS

[0055] In order to more clearly illustrate the technical solutions in the application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative effort on the basis of these drawings.

[0056] Figure 1 One of the flowcharts of the permission control method provided by the application;

[0057] Figure 2 The second flowchart of the permission control method provided by the application;

[0058] Figure 3 The structural schematic diagram of the permission control device provided by the application;

[0059] Figure 4A structural schematic diagram of an electronic device provided by the present application. DETAILED DESCRIPTION

[0060] In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions in the present application will be described clearly and completely below with reference to the drawings in the present application. Obviously, the described embodiments are some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0061] In an operating system, dbus provides powerful and flexible cross-process communication functions. For some services involving security, the API provided by the service can only be called by an authorized client, and therefore permission management is required for API call requests.

[0062] Dbus itself provides a set of security management solutions, which control the calling of related APIs by clients through setting corresponding service permissions in a configuration file. The configuration file provided by dbus can control whether a user can start a service and whether the user can send a message to the service or an interface under the service. However, the user-mode configuration file can be modified, thereby bypassing the security management of service calling and causing certain security risks. For example, due to the special permissions of some special accounts (for example, a root account) of an operating system, the configuration in the configuration file can also be directly modified, that is, the configuration in the configuration file can be directly modified using a root account.

[0063] For ease of understanding, take service configuration as an example, and the corresponding dbus configuration file is as follows:

[0064]

[0065] Among them, the configuration 1 indicates that the normal user cannot start the service, and it is set to deny the start of any service name by deny. The configuration 2 indicates that the root user can start the service, but can only start the service with the service name "Rose.LocalPropertyRepository", and it is set to deny all services by deny, and then set to start the service with the service name "Rose.LocalPropertyRepository" by allow. The configuration 3 indicates that only the "Rose.LocalPropertyRepository.Internal" interface under the "Rose.LocalPropertyRepository" service can be sent a message, and other interfaces under the service cannot be sent a message. The configuration 4 indicates that the right to start the service and the right to send a message are controlled by SELinux, and whether it can be started based on the "Rose.LocalPropertyRepository" service name is determined by the label "service_own_name_t".

[0066] Currently, in order to make the configuration in the configuration file not be modified, dbus further adapts SELinux (Security-Enhanced Linux). By modifying the internal code of dbus, it is supported to control whether the service can be started based on a service name through SELinux, and it is also supported to control the message sending of process A to process B, the permission check is completed in the kernel mode, and the possibility of modifying the user mode configuration file is avoided. For example, based on the mechanism of SELinux "label in advance + bool variable control", the overall message sending of process A to process B can be controlled, that is, all messages can be sent or all messages cannot be sent. However, SELinux controls the permission based on the white list mechanism, only the client object listed in the white list has the permission to access, that is, only the client object meeting the configuration requirement has the permission to access. Based on this, although SELinux can control the client to call the service without modifying the dbus configuration file, all terminals need to be labeled to perform the permission control of the white list mechanism, and some terminals do not have the permission control requirement, so that the label is introduced additionally, and then resource and performance are wasted, and the system performance is reduced. For example, the message sending to process B needs to be authorized, only process A can send the message to process B, so the "blksec_clt_send_t" label of authorization is given to process A. Due to the introduction of SELinux, the whole system needs to be labeled, but the whole system actually does not have other control requirements. Although the label of default permission can be given, the additional labels are also a waste of resources and performance.

[0067] To solve the above problems, the present application provides the following embodiments. Figure 1 One of the flowcharts of the permission control method provided by the present application is shown in Figure 1 The permission control method applied to the server includes the following steps.

[0068] In step 110, an API call request sent by a client is received, and a target service accessed based on the API call request is determined.

[0069] Here, the API call request is used to call the API of the target service accessed. In an embodiment, the client is the target service service of the server, and the API call request is sent to the target service service. First, the API call request is sent to the service daemon, and then routed to the target service service.

[0070] In step 120, the first permission control attribute of the server for the target service is queried.

[0071] If there is permission control for the target service, the first permission control attribute is configured for the target service, so that the first permission control attribute can be queried; if there is no permission control for the target service, the first permission control attribute is not configured for the target service, so that the first permission control attribute cannot be queried.

[0072] In an embodiment, the first permission control attribute is configured on a file corresponding to the target service, i.e., on a process file corresponding to the target service, i.e., the first permission control attribute is an extended attribute on the file, so as to realize dynamic configuration of the first permission control attribute, i.e., dynamic tagging, which can dynamically tag the target service compared with static tagging.

[0073] In an embodiment, the first permission control attribute of the target service on the server side is queried based on a first Socket sent by the client. The first Socket and a second Socket of the client itself have a reference relationship, and the first permission control attribute is stored in the first Socket, so that the first permission control attribute can be queried based on the first Socket sent by the client.

[0074] In step 130, if the first permission control attribute is not queried, the API call request is routed to the target service.

[0075] Specifically, if the first permission control attribute is not queried, it means that the server side does not need to do permission control for the target service, so the API call request can be directly routed to the target service for responding to the API call request.

[0076] In step 140, if the first permission control attribute is queried, the API call request of the client is subjected to permission verification.

[0077] Specifically, if the first permission control attribute is queried, it means that the server side needs to do permission control for the target service, so the API call request of the client is subjected to permission verification to determine whether to route the API call request to the target service.

[0078] It should be understood that by the above method, the black list mechanism is introduced on the basis of the original white list mechanism, i.e., there is no permission control by default and there is permission control only when it is configured, which can effectively solve the problem of resource waste in the SELinux based on bool variable to realize "dynamic" permission control.

[0079] The permission control method provided by the embodiments of the present application receives an API calling request sent by a client, determines a target service accessed based on the API calling request, queries a first permission control attribute of the target service on a server, and routes the API calling request to the target service if the first permission control attribute is not queried, so that the server does not control the permission of the target service without the first permission control attribute, and the API calling request can be routed to the target service directly, that is, no permission control is defaulted without the first permission control attribute, and the API calling request of the client is verified only if the first permission control attribute is queried, that is, the server controls the permission of the target service only if the first permission control attribute is configured, and the API calling request of the client is verified only then, so that all terminals and services do not need to be labeled, and the first permission control attribute only needs to be configured for the services that need permission control, thereby reducing the waste of resources and performance and improving the system performance.

[0080] Based on any of the above embodiments, Figure 2 For the flowchart of the permission control method provided by the present application, as shown in Figure 2 The step 140 of verifying the permission of the API calling request of the client includes the following steps.

[0081] Step 141, if the first permission control attribute is queried, a second permission control attribute of the target service of the client is queried.

[0082] If the client has no permission to access the target service, the second permission control attribute of the target service of the client will not be configured, so that the API calling request is refused to be routed to the target service if the second permission control attribute is not queried, and if the client has the permission to access the target service, the second permission control attribute of the target service of the client will be configured, so that the API calling request is verified based on the first permission control attribute and the second permission control attribute to determine whether the client has the permission to access the target service if the second permission control attribute is queried.

[0083] In an embodiment, the second permission control attribute is configured on the corresponding process file of the client, that is, the second permission control attribute is an extended attribute on the file, so that the second permission control attribute is dynamically configured, that is, the dynamic labeling is realized, and the target service can be dynamically labeled compared with the static labeling.

[0084] Step 142, if the second permission control attribute is queried, the API calling request is verified based on the first permission control attribute and the second permission control attribute to obtain a permission verification result.

[0085] It should be understood that if the second permission control attribute is queried, it means that the second permission control attribute is obtained from the client.

[0086] Specifically, the API call request is checked for permission based on the kernel state, that is, the permission check itself is trapped into the kernel state, and the permission check result is returned by the kernel state. It should be understood that the permission control of cross-process communication is realized based on the MAC (Mandatory Access Control) mechanism, so that the permission check of the client application calling the service is completed in the kernel state, which solves the possibility of modifying the user state configuration file, avoids potential problems such as bypassing the security control mechanism through a special permission account, and improves the security of the permission control.

[0087] In step 143, if the permission check result is permission, the API call request is routed to the target service.

[0088] If the permission check result is permission, the API call request can be routed to the target service for the target service to respond to the API call request; if the permission check result is no permission, the API call request is refused to be routed to the target service, that is, the API call request is refused to be responded.

[0089] The permission control method provided by the embodiment of the application queries the second permission control attribute of the client for the target service only when the first permission control attribute is queried, so that the second permission control attribute of the client for the target service is queried only when the server needs to control the permission for the target service, thereby improving the system performance. The API call request is checked for permission based on the first permission control attribute and the second permission control attribute only when the second permission control attribute is queried, thereby reducing the waste of resources and performance and improving the system performance.

[0090] Based on any of the above embodiments, the method comprises the following steps:

[0091] The second permission control attribute of the client for the target service is queried based on a first socket Socket sent by the client;

[0092] The first Socket and a second Socket of the client itself have a reference relationship, the first Socket stores the first permission control attribute, and the second Socket stores the second permission control attribute, so that the server can query the second permission control attribute based on the first Socket.

[0093] Specifically, the process is usually based on socket communication, in order to control the authority of socket, the first authority control attribute or the second authority control attribute stored in the socket can directly inherit the first authority control attribute or the second authority control attribute of the process. That is, the first authority control attribute or the second authority control attribute is directly saved to the security member variable of the socket.

[0094] In a specific embodiment, when opening the process file to create inode, the first authority control attribute or the second authority control attribute is saved to the security member variable of the inode; when starting the process, the first authority control attribute or the second authority control attribute of the inode is saved to the process context; when creating a socket inside the process, the first authority control attribute or the second authority control attribute of the process context is saved to the socket. The above can be processed by the security hook function. Since the process has a process context, many controls are based on the process, and in order to facilitate indexing, the first authority control attribute or the second authority control attribute of the inode is saved to the process context.

[0095] Considering that the above only completes the inheritance of the first authority control attribute or the second authority control attribute of the process to the socket, but the communication between the sockets is mutual communication, and the control itself also needs two objects of subject and object, so the two sockets are just the relationship of subject and object. Based on this, in order to improve the communication performance of the socket, a reference is set between the first socket and the second socket of the client itself, so as to improve the query efficiency of the first authority control attribute or the second authority control attribute, and further improve the efficiency and performance of the authority control.

[0096] It should be noted that in order to enable the authority control attributes of both parties (i.e. the client and the server) to be immediately found from the socket data structure of their own, and in addition to knowing their own authority control attributes, they also need to know the authority control attributes of the other party, therefore, a reference is set between the first socket and the second socket of the client itself, so as to improve the query efficiency of the authority control attribute, and further improve the efficiency and performance of the authority control.

[0097] Among them, the server communicates with the client through the first socket sent by the client.

[0098] In a specific embodiment, the client initiatively makes a Socket connection with the server, i.e. the user state triggers a call of connect, and the server user state triggers a call of accept to receive the connection; when the client connects, the previous Socket (cltsock) is searched out according to the fd (File Descriptor), and the second authority control attribute is obtained from the cltsock for security, and the client needs to create a new first Socket (newsk), which is used for point-to-point communication with the server. A client can create multiple point-to-point connections with the server, and thus multiple newsk are created. The newsk is finally sent to the server, and the final communication occurs between cltsock->sk and newsk after the connection is successful. Therefore, there is a reference between the first Socket and the second Socket of the client, for example, through the peer reference, sk->peer = newsk, and newsk->peer = sk. The sk (second Socket) and the newsk (first Socket) can access each other, which enables them to directly communicate with each other. The permission check information before the communication is also saved in the sk and the newsk. Based on this, after the mutual reference is completed, the permission check can be completed by both the client and the server. For ease of understanding the reference, the following is shown:

[0099] sk->blksec_id = blksec_id of the client process (second authority control attribute);

[0100] newsk->blksec_id = blksec_id of the server process (first authority control attribute);

[0101] sk->peer_blksec_id = newsk->blksec_id;

[0102] newsk->peer_blksec_id = sk->blksec_id.

[0103] In addition, it should be noted that the second Socket can be found in the client process through the fd of the client, and the first Socket can be found in the server process through the newly created fd. Therefore, the user state can complete mutual communication based on the fd, and can also complete mutual authority control.

[0104] It should be understood that the first Socket and the second Socket point to each other, so that they can quickly obtain the authority control attribute of each other, thereby improving the query efficiency of the authority control attribute, and thereby improving the efficiency and performance of the authority control.

[0105] It should be understood that since the first permission control attribute and the second permission control attribute are permission control attributes of two processes, checking the permissions between Socket communications is actually checking whether the two processes can communicate through Socket.

[0106] The permission control method provided by the embodiments of the present application can quickly query the second permission control attribute of the other party based on the first Socket sent by the client and the second Socket of the client itself, thereby improving the query efficiency of the second permission control attribute and the efficiency and performance of the permission control.

[0107] Based on any of the above embodiments, in the method, the first permission control attribute is generated based on the following manner:

[0108] An extended attribute configured on a file corresponding to the target service is obtained;

[0109] A first key of a hash table is determined based on the extended attribute;

[0110] If the first key is found in the hash table based on the first key, a position of the first key in the hash table is determined as the first permission control attribute;

[0111] If the first key is not found in the hash table based on the first key, the first key is inserted into the hash table, and an insertion position of the first key in the hash table is determined as the first permission control attribute.

[0112] In the prior art, SELinux is static labeling, that is, it must be set with application labels in advance and cannot achieve dynamic labeling, that is, it cannot flexibly solve the problem of dynamically setting permission control. For example, how many clients send messages to process B cannot be known in advance, and since SELinux must be statically labeled in advance, the number of labels must be defined in advance, such as 128 labels. Dynamic control needs to be implemented based on a bool variable, and since the label resources are limited, the labels can only be statically planned according to the existing applications in the system, such as application 1 labeled 1, application 2 labeled 2, and application 128 labeled 128, and the running process controls the permission of sending messages to process B by modifying the value of the bool variable. However, there are more than 128 applications, and the number of labels is not enough, and the 128 applications do not necessarily call the service of sending messages to process B, and such a white list static planning label mechanism will cause a huge waste of resources. Therefore, the extended attribute configured on the file corresponding to the target service is obtained to achieve dynamic labeling, that is, the extended attribute is configured on the file according to the actual demand, that is, the function of dynamically labeling the application is achieved, and the problem of insufficient number of labels and difficult effective planning is flexibly solved. Correspondingly, the kernel also needs to dynamically add the extended attribute, that is, the kernel needs to support the mechanism of dynamically adding and parsing the extended attribute according to the demand, and the added permission can only be given to a specific security service process.

[0113] Specifically, the extended attribute configured on the process file corresponding to the target service is obtained. In a specific embodiment, when the process file is loaded, that is, when the target service (process) is started, the file system supports reading and writing the extended attribute; the system function is called when the process is opened, so as to call the corresponding security hook function, that is, the do_filp_open function of the kernel is called when the process is executed, and finally the security opening hook function is called, and only the security hook of the kernel LSM (Linux Security Module) mechanism needs to be registered; the security hook function reads the extended attribute; if the extended attribute exists, it indicates that permission control is needed, and the value of the extended attribute is read out.

[0114] For example, the extended attribute is "system_u:object_r:blksec_srv_1_t:s0", and the extended attribute is used as the first key of the hash table.

[0115] Further, the first permission control attribute is saved into a security member variable of an inode. Since the parsing of the extended attribute occurs when a process file is first loaded, which is the moment when the inode node of the file is created, the parsed extended attribute value is saved into the data structure corresponding to the inode node. Since it is saved into the data structure corresponding to the inode node, it is parsed only once, thereby ensuring performance. In other words, the file is opened only once to create a unique inode, and the extended attribute is parsed only once, so the first permission control attribute is saved in the security member variable in the inode after being parsed from the extended attribute.

[0116] Further, since the target service is a process, the first permission control attribute is further saved into a security member variable of a process context when the kernel initializes the process. In this way, the first permission control attribute can be obtained when the process communicates via a socket as a subject.

[0117] Further, the security hook function is only a hook function in the entire opening process when the process is opened. After the security hook function is called, it needs to return to the function that called it. Regardless of the situation, OK is returned, because the extended attribute is not necessary, and it is a basic principle of this security module to control only when it is set.

[0118] It should be noted that the second permission control attribute is generated in a manner basically the same as that of the first permission control attribute, which will not be described herein again.

[0119] The permission control method provided by the embodiments of the present application acquires the extended attribute configured on the file corresponding to the target service, to realize dynamic tagging, that is, dynamically configuring the extended attribute on the file according to actual requirements, to realize the function of dynamically tagging the application, and flexibly solve the problem of insufficient number of tags and difficulty in effective planning. Based on the extended attribute, the first key of the hash table is determined. If the first key is found in the hash table based on the first key, the position of the first key in the hash table is determined as the first permission control attribute. If the first key is not found in the hash table based on the first key, the first key is inserted into the hash table, and the insertion position of the first key in the hash table is determined as the first permission control attribute. In this way, the extended attribute is converted into the integer-valued first permission control attribute through the hash table, the query efficiency of the first permission control attribute is improved, and the efficiency and performance of the permission control are further improved.

[0120] Based on any of the above embodiments, in the method, the first key of the hash table is determined based on the extended attribute, including:

[0121] The extended attribute is split according to types to obtain a plurality of attributes.

[0122] respectively as second keys of a lookup hash table;

[0123] based on each of the second keys, looking up the hash table to determine a target position of each of the second keys in the hash table;

[0124] based on an integer value of each of the target positions, determining the first key.

[0125] For example, the extended attribute is "system_u:object_r:blksec_srv_1_t:s0", the extended attribute is split according to the types user, role, type and class to obtain multiple attributes system_u, object_r, blksec_srv_1_t and s0; multiple attributes system_u, object_r, blksec_srv_1_t and s0 are respectively taken as second keys key, and their positions in the hash table are looked up; the target position of each second key in the hash table is an integer value corresponding to the second key; the integer value of each target position is encapsulated into a security context, the security context includes the integer value of each target position, and the security context is taken as the first key.

[0126] The permission control method provided by the embodiment of the present application can obtain more first keys by combining multiple attributes, thereby reducing the number of configurations of the hash table and reducing the cost of permission control.

[0127] Based on any of the above embodiments, the present application further provides a permission control method applied to a client, the permission control method applied to the client comprising:

[0128] sending an API call request to a server, so that the server performs permission verification on the API call request.

[0129] The server performs permission verification on the API call request in the following manner:

[0130] determining a target service accessed based on the API call request; querying a first permission control attribute of the target service of the server; if the first permission control attribute is not queried, routing the API call request to the target service; if the first permission control attribute is queried, performing permission verification on the API call request of the client.

[0131] Here, the service end can refer to the above-mentioned embodiments for the step of performing permission verification on the API calling request, which will not be repeated here. It should be understood that the client can also act as a service end and perform the steps of the service end.

[0132] The permission control method provided by the embodiments of the present application sends an API calling request to a service end, so that the service end determines a target service accessed based on the API calling request, queries a first permission control attribute of the service end for the target service, and routes the API calling request to the target service if the first permission control attribute is not queried, so that in the case where the first permission control attribute is not configured, it is confirmed that the service end does not control the permission for the target service, and the API calling request can be directly routed to the target service, that is, no permission control is defaulted without configuration. Only when the first permission control attribute is queried, the permission verification on the API calling request of the client is performed, that is, it is confirmed that the service end controls the permission for the target service only when the first permission control attribute is configured, and then the permission verification on the API calling request of the client is needed, so that all terminals and services do not need to be labeled, and only the first permission control attribute needs to be configured for the service that needs permission control, thereby reducing the waste of resources and performance and improving the system performance.

[0133] Based on any of the above-mentioned embodiments, in the method, if the first permission control attribute is queried by the service end, the step of sending the API calling request to the service end further includes:

[0134] Based on the second Socket of the client itself, the second permission control attribute of the client is sent to the service end;

[0135] The second Socket and the first Socket of the service end have a reference relationship, the first Socket stores the first permission control attribute, and the second Socket stores the second permission control attribute, so that the client can send the second permission control attribute to the service end based on the second Socket; and the first Socket is created by the client and sent to the service end.

[0136] Specifically, the process is usually based on Socket communication, and in order to control the permission of the socket, the first permission control attribute or the second permission control attribute stored in the Socket can directly inherit the first permission control attribute or the second permission control attribute of the process. That is, the first permission control attribute or the second permission control attribute is directly saved to the security member variable of the Socket.

[0137] It is to be noted that in order to make the permission control attributes of both the client and the server immediately found from the own Socket data structure, and in addition to knowing the permission control attributes of the own, the permission control attributes of the other party also need to be known, therefore the reference between the first Socket and the second Socket of the client itself is set, the query efficiency of the first permission control attribute or the second permission control attribute is improved, and the efficiency and performance of the permission control are further improved.

[0138] It is to be noted that in order to make the permission control attributes of both the client and the server immediately found from the own Socket data structure, and in addition to knowing the permission control attributes of the own, the permission control attributes of the other party also need to be known, therefore the reference between the first Socket and the second Socket of the client itself is set, the query efficiency of the first permission control attribute or the second permission control attribute is improved, and the efficiency and performance of the permission control are further improved.

[0139] The first Socket sent by the server through the client is used for Socket communication with the client.

[0140] In a specific embodiment, the client initiatively performs Socket connection with the server, that is, the user state triggers the connect, and the server user state triggers the accept to receive the connection; when the client is connected, the previous Socket (cltsock) is searched out according to the fd (File Descriptor), the second permission control attribute is obtained from the cltsock for security, and the client needs to create a new first Socket (newsk), which is used for point-to-point communication with the server, one client can create multiple point-to-point with the server, and therefore multiple newsk are created; the newsk is finally sent to the server, and the final communication occurs between the cltsock->sk and the newsk after the connection is successful, therefore, the reference exists between the first Socket and the second Socket of the client itself, for example, through the peer reference, sk->peer=newsk, and newsk->peer=sk; the sk (second Socket) and the newsk (first Socket) can access each other, and they can directly communicate with each other, and the permission check information before the communication is also saved in the sk and the newsk. Based on this, after the mutual reference is completed, the permission check can be completed by both the client and the server. In order to facilitate understanding of the reference, the following is shown:

[0141] sk->blksec_id = the blksec_id of the client process (the second authority management attribute) ;

[0142] newsk->blksec_id = the blksec_id of the server process (the first authority management attribute) ;

[0143] sk->peer_blksec_id = newsk->blksec_id;

[0144] newsk->peer_blksec_id = sk->blksec_id.

[0145] In addition, it should be noted that the second Socket can be found by the client process through the fd of the client, and the first Socket can be finally found by the server process through the newly created fd, so that the user plane can complete mutual communication based on the fd, and mutual authority management can also be completed.

[0146] It should be understood that the first Socket and the second Socket point to each other, so that the authority management attributes of the other party can be quickly obtained, thereby improving the query efficiency of the authority management attributes, and thereby improving the efficiency and performance of the authority management.

[0147] It should be understood that since the first authority management attribute and the second authority management attribute are the authority management attributes of two processes, checking the authority between Socket communication is actually checking whether the two processes can perform Socket communication.

[0148] The authority management method provided by the embodiment of the application sends the second authority management attribute of the client to the server based on the second Socket of the client itself, and there is a reference between the first Socket and the second Socket of the client itself, so that the second authority management attribute can be quickly sent, thereby improving the query efficiency of the second authority management attribute, and thereby improving the efficiency and performance of the authority management.

[0149] The authority management device provided by the application will be described below, and the authority management device described below can be correspondingly referred to the authority management method described above.

[0150] Figure 3 The structure diagram of the authority management device provided by the application is shown in Figure 3 As shown in the figure, the authority management device deployed in the server includes:

[0151] The request receiving module 310 is configured to receive an API call request sent by a client, and determine a target service accessed based on the API call request;

[0152] The attribute query module 320 is configured to query the first permission control attribute of the target service of the service end.

[0153] The request routing module 330 is configured to, if the first permission control attribute is not queried, route the API calling request to the target service.

[0154] The permission verification module 340 is configured to, if the first permission control attribute is queried, perform permission verification on the API calling request of the client.

[0155] The permission control device provided by the embodiment of the application receives an API calling request sent by a client, determines a target service accessed based on the API calling request, queries a first permission control attribute of the target service of a service end, and routes the API calling request to the target service if the first permission control attribute is not queried, so that, in the case where the first permission control attribute is not configured, it is confirmed that the service end does not perform permission control on the target service, and the API calling request can be directly routed to the target service, that is, no permission control is performed by default if no configuration is performed, and permission verification is performed on the API calling request of the client only if the first permission control attribute is queried, that is, it is confirmed that the service end performs permission control on the target service only if the first permission control attribute is configured, and then permission verification needs to be performed on the API calling request of the client, so that all terminals and services do not need to be labeled, and the first permission control attribute only needs to be configured for a service that needs permission control, thereby reducing waste of resources and performance and improving system performance.

[0156] The permission control device deployed on the client comprises:

[0157] The request sending module is configured to send an API calling request to a service end, so that the service end performs permission verification on the API calling request.

[0158] The service end performs permission verification on the API calling request in the following manner:

[0159] Determine a target service accessed based on the API calling request.

[0160] Query a first permission control attribute of the target service of the service end.

[0161] If the first permission control attribute is not queried, route the API calling request to the target service.

[0162] If the first permission control attribute is queried, perform permission verification on the API calling request of the client.

[0163] Figure 4An example of a schematic diagram of a physical structure of an electronic device is shown in Figure 4 As shown, the electronic device can include a processor 410, a communications interface 420, a memory 430, and a communications bus 440, wherein the processor 410, the communications interface 420, and the memory 430 can communicate with each other through the communications bus 440. The processor 410 can invoke a logical instruction in the memory 430 to execute a permission control method applied to a server, the method including: receiving an API call request sent by a client, determining a target service accessed based on the API call request; querying a first permission control attribute of the target service of the server; if the first permission control attribute is not queried, routing the API call request to the target service; and if the first permission control attribute is queried, performing permission verification on the API call request of the client. Alternatively, a permission control method applied to a client is executed, the method including: sending an API call request to a server for the server to perform permission verification on the API call request; wherein the server performs permission verification on the API call request in the following manner: determining a target service accessed based on the API call request; querying a first permission control attribute of the target service of the server; if the first permission control attribute is not queried, routing the API call request to the target service; and if the first permission control attribute is queried, performing permission verification on the API call request of the client.

[0164] In addition, the logical instruction in the memory 430 described above can be implemented in the form of a software functional unit and sold or used as an independent product, which can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the present application or the part of the technical solutions that essentially contribute to the prior art or the part of the technical solutions can be embodied in the form of a software product, which is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0165] In another aspect, the present application also provides a computer program product, which comprises a computer program, the computer program being stored in a non-transitory computer-readable storage medium, and the computer program being executable by a processor to enable a computer to perform the permission control method for a server provided by any of the above methods, the method comprising: receiving an API call request sent by a client, determining a target service accessed based on the API call request; querying a first permission control attribute of the target service of the server; if the first permission control attribute is not queried, routing the API call request to the target service; and if the first permission control attribute is queried, performing permission verification on the API call request of the client. Alternatively, the computer program is executable by the processor to enable the computer to perform the permission control method for a client provided by any of the above methods, the method comprising: sending an API call request to a server for the server to perform permission verification on the API call request; and wherein the server performs permission verification on the API call request in the following manner: determining a target service accessed based on the API call request; querying a first permission control attribute of the target service of the server; if the first permission control attribute is not queried, routing the API call request to the target service; and if the first permission control attribute is queried, performing permission verification on the API call request of the client.

[0166] In yet another aspect, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, the computer program being executable by a processor to implement the permission control method for a server provided by any of the above methods, the method comprising: receiving an API call request sent by a client, determining a target service accessed based on the API call request; querying a first permission control attribute of the target service of the server; if the first permission control attribute is not queried, routing the API call request to the target service; and if the first permission control attribute is queried, performing permission verification on the API call request of the client. Alternatively, the computer program is executable by the processor to implement the permission control method for a client provided by any of the above methods, the method comprising: sending an API call request to a server for the server to perform permission verification on the API call request; and wherein the server performs permission verification on the API call request in the following manner: determining a target service accessed based on the API call request; querying a first permission control attribute of the target service of the server; if the first permission control attribute is not queried, routing the API call request to the target service; and if the first permission control attribute is queried, performing permission verification on the API call request of the client.

[0167] The device embodiments described above are merely illustrative, wherein the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed to multiple network units. Part or all of the modules can be selected to achieve the purposes of the embodiments according to actual needs. Those skilled in the art can understand and implement without creative labor.

[0168] Through the description of the above embodiments, those skilled in the art can clearly understand that the embodiments can be realized by means of software and the necessary general hardware platform, and of course can also be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of a software product, which can be stored in a computer readable storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiments.

[0169] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement to part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for controlling access permissions, characterized in that, Applied to a server, the method comprises: receiving an API call request sent by a client, determining a target service accessed based on the API call request; inquiring a first permission control attribute of the server for the target service; if the first permission control attribute is not inquired, routing the API call request to the target service; if the first permission control attribute is inquired, performing permission verification on the API call request of the client; the permission verification on the API call request of the client comprises: inquiring a second permission control attribute of the client for the target service; if the second permission control attribute is inquired, performing permission verification on the API call request based on the first permission control attribute and the second permission control attribute to obtain a permission verification result; if the permission verification result is permission, routing the API call request to the target service; inquiring the second permission control attribute of the client for the target service comprises: inquiring the second permission control attribute of the client for the target service based on a first socket sent by the client; wherein the first socket and a second socket of the client itself have a reference, the first socket stores the first permission control attribute, and the second socket stores the second permission control attribute, so that the server can inquire the second permission control attribute based on the first socket.

2. The method of claim 1, wherein, The first permission control attribute is generated based on the following way: obtaining an extended attribute configured on a file corresponding to the target service; determining a first key of a hash table based on the extended attribute; if the first key is found in the hash table based on the first key, the position of the first key in the hash table is determined as the first permission control attribute; if the first key is not found in the hash table based on the first key, the first key is inserted into the hash table, and the insertion position of the first key in the hash table is determined as the first permission control attribute.

3. The method of claim 2, wherein, The first key of the hash table is determined based on the extended attribute, comprising: splitting the extended attribute according to types to obtain a plurality of attributes; respectively taking the plurality of attributes as second keys for inquiring a hash table; inquiring the hash table based on each second key to determine a target position of each second key in the hash table; determining the first key based on the integer value of each target position.

4. A method for managing rights, characterized by Applied to a client, the method comprises: sending an API call request to a server for the server to perform permission verification on the API call request; wherein the server performs permission verification on the API call request based on the following way: determining a target service accessed based on the API call request; inquiring a first permission control attribute of the server for the target service; If the first permission control attribute is not queried, the API calling request is routed to the target service; If the first permission control attribute is queried, the API calling request of the client is subjected to permission verification; The permission verification of the API calling request of the client comprises: querying a second permission control attribute of the client for the target service; If the second permission control attribute is queried, the API calling request is subjected to permission verification based on the first permission control attribute and the second permission control attribute to obtain a permission verification result; If the permission verification result is permission, the API calling request is routed to the target service; If the service side queries the first permission control attribute, the sending of the API calling request to the service side further comprises: sending a second permission control attribute of the client to the service side based on a second Socket of the client itself; The second Socket and the first Socket of the service side have a reference relationship, the first Socket stores the first permission control attribute, and the second Socket stores the second permission control attribute, so that the client can send the second permission control attribute to the service side based on the second Socket; The first Socket is created by the client and sent to the service side.

5. A device for managing rights, characterized in that The device is deployed on a service side and comprises: a request receiving module configured to receive an API calling request sent by a client and determine a target service accessed based on the API calling request; an attribute querying module configured to query a first permission control attribute of the service side for the target service; a request routing module configured to route the API calling request to the target service if the first permission control attribute is not queried; a permission verification module configured to subject the API calling request of the client to permission verification if the first permission control attribute is queried; The permission verification of the API calling request of the client comprises: querying a second permission control attribute of the client for the target service; If the second permission control attribute is queried, the API calling request is subjected to permission verification based on the first permission control attribute and the second permission control attribute to obtain a permission verification result; If the permission verification result is permission, the API calling request is routed to the target service; The querying of the second permission control attribute of the client for the target service comprises: querying a second permission control attribute of the client for the target service based on a first Socket sent by the client; The first Socket and a second Socket of the client itself have a reference relationship, the first Socket stores the first permission control attribute, and the second Socket stores the second permission control attribute, so that the service side can query the second permission control attribute based on the first Socket.

6. A rights management device, characterized by comprising: A device deployed on a client, the device comprising: a request sending module configured to send an API calling request to a server for the server to perform permission check on the API calling request; wherein the server performs permission check on the API calling request based on the following manners: determining a target service accessed based on the API calling request; inquiring a first permission control attribute of the target service from the server; if the first permission control attribute is not inquired, routing the API calling request to the target service; if the first permission control attribute is inquired, performing permission check on the API calling request of the client; the permission check on the API calling request of the client comprises: inquiring a second permission control attribute of the target service from the client; if the second permission control attribute is inquired, performing permission check on the API calling request based on the first permission control attribute and the second permission control attribute to obtain a permission check result; if the permission check result is permission, routing the API calling request to the target service; if the first permission control attribute is inquired from the server, the request sending module is further configured to: send the second permission control attribute of the client to the server based on a second Socket of the client itself; wherein the second Socket and a first Socket of the server have reference relationship, the first Socket stores the first permission control attribute, and the second Socket stores the second permission control attribute, so that the client can send the second permission control attribute to the server based on the second Socket; the first Socket is created by the client and sent to the server.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the permission control method of any one of claims 1 to 4.

8. A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the permission control method of any one of claims 1 to 4.

9. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the permission control method of any one of claims 1 to 4.

Images