Permission processing method and device, equipment, storage medium and vehicle

Abstract

The invention discloses a permission processing method and device, equipment, a storage medium and a vehicle. The method comprises the steps that a target instruction and user information issued by an upper-layer application to a bottom-layer authentication service are obtained, a target permission corresponding to the target instruction is an administrator permission, and the target permission is larger than an application permission of the upper-layer application; verifying the user information through the underlying authentication service to obtain a verification result; determining the target permission corresponding to the target instruction according to the corresponding relationship between the instruction and the permission under the condition that the verification result is that the verification is passed; and executing the target instruction according to the target permission. According to the permission processing method provided by the embodiment of the invention, the security of the operating system can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a permission processing method, apparatus, device, storage medium, and vehicle. Background Art

[0002] In an operating system, applications typically run as a user. These users can include regular users and administrators (root users). Administrators have the highest permissions in the operating system, allowing them to fully control the device's operating system and software environment. Regular users have limited permissions. The actual operation of an operating system often involves privilege escalation. Privilege escalation refers to the process of a user gaining higher permissions in a computer system. Privilege escalation typically involves raising regular user permissions to administrator permissions, which grants greater access and control.

[0003] Currently, user versions of operating systems typically include the su and sudo files. Using the su or sudo commands allows privilege escalation (i.e., switching from a regular user to an administrator). However, these commands are global privilege escalation tools and cannot restrict specific process access or privilege escalation. This leads to the risk of programs abusing their privileges to perform illegal operations, compromising operating system security. Summary of the Invention

[0004] Embodiments of the present application provide a permission processing method, apparatus, device, storage medium, and vehicle, which can improve the security of an operating system.

[0005] In a first aspect, an embodiment of the present application provides a permission processing method, the method comprising:

[0006] Obtaining the target instruction and user information sent by the upper-layer application to the underlying authentication service, wherein the target permission corresponding to the target instruction is the administrator permission, and the target permission is greater than the application permission of the upper-layer application;

[0007] Verify the user information through the underlying authentication service to obtain a verification result;

[0008] If the verification result is that the verification passes, determining the target permission corresponding to the target instruction according to the correspondence between instructions and permissions;

[0009] Execute the target instruction according to the target permission.

[0010] In a possible implementation, before determining the target permission corresponding to the target instruction according to the correspondence between instructions and permissions, the method further includes:

[0011] Setting a correspondence between the instruction and the permission in a permission configuration file;

[0012] Adding the rights configuration file to the executable file corresponding to the underlying authentication service;

[0013] The determining the target permission corresponding to the target instruction according to the correspondence between the instruction and the permission includes:

[0014] The target permission corresponding to the target instruction is determined according to the corresponding relationship between the instruction and the permission through the underlying authentication service.

[0015] In one possible implementation, obtaining the target instruction and user information sent by the upper-layer application to the lower-layer authentication service includes:

[0016] The target instruction and the user information sent by the upper layer application to the underlying authentication service through the secure socket layer protocol are obtained.

[0017] In one possible implementation, the user information includes a digital certificate and token information, wherein the digital certificate is used to uniquely identify the identity of the upper-layer application, and the token information is user identity information generated by the authentication server when the login information of the upper-layer application is successfully verified;

[0018] The verifying the user information to obtain a verification result includes:

[0019] Verifying the digital certificate to obtain a certificate verification result;

[0020] Verifying the token information to obtain a token verification result;

[0021] The verification result is determined according to the certificate verification result and the token verification result.

[0022] In a possible implementation, before obtaining the target instruction and user information sent by the upper-layer application to the lower-layer authentication service, the method further includes:

[0023] Sending the login information to the authentication server so that the authentication server verifies the login information, and generating and sending the token information to the client if the login information is successfully verified;

[0024] Receive the token information sent by the authentication server.

[0025] In a possible implementation, before obtaining the target instruction and user information sent by the upper-layer application to the lower-layer authentication service, the method further includes:

[0026] The digital certificate is configured for the upper-layer application.

[0027] In a second aspect, an embodiment of the present application provides a rights processing device, the device comprising:

[0028] An acquisition module is used to obtain a target instruction and user information sent by an upper-layer application to a lower-layer authentication service, wherein the target permission corresponding to the target instruction is an administrator permission, and the target permission is greater than the application permission of the upper-layer application;

[0029] A verification module, configured to verify the user information through the underlying authentication service and obtain a verification result;

[0030] a determination module, configured to determine, if the verification result is a passed verification, the target permission corresponding to the target instruction based on the correspondence between instructions and permissions;

[0031] An execution module is used to execute the target instruction according to the target permission.

[0032] In a third aspect, an embodiment of the present application provides an electronic device, the electronic device comprising: a processor and a memory storing computer program instructions;

[0033] When the processor executes the computer program instructions, the method in any possible implementation method of the first aspect described above is implemented.

[0034] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the method of any possible implementation method in the first aspect described above is implemented.

[0035] In a fifth aspect, an embodiment of the present application provides a vehicle, the vehicle comprising at least one of the following:

[0036] The rights processing device according to any one of the embodiments of the second aspect;

[0037] The electronic device according to any one of the embodiments of the third aspect;

[0038] A computer-readable storage medium as in any embodiment of the fourth aspect.

[0039] In the permission processing method, apparatus, device, storage medium and vehicle of the embodiments of the present application, since the target permission corresponding to the target instruction is the administrator permission, which is greater than the application permission of the upper-layer application, in order to be able to execute the target instruction, it is necessary to perform permission escalation processing on the process corresponding to the target instruction. By verifying the user information of the upper-layer application, and determining the target permission corresponding to the target instruction based on the correspondence between the instruction and the permission when the verification result is that the verification passes, limited administrator permissions can be provided to the process executing the target instruction, rather than all administrator permissions. In this way, by executing the target instruction according to the target permission, the risk of the program abusing permissions to perform illegal operations can be avoided, thereby improving the security of the operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0041] Figure 1 This is a flowchart of a permission processing method provided in an embodiment of the present application;

[0042] Figure 2 This is a flowchart of another permission processing method provided in an embodiment of the present application;

[0043] Figure 3 This is a schematic diagram of the structure of a permission processing device provided in an embodiment of the present application;

[0044] Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to more clearly understand the above-mentioned objectives, features and advantages of the present application, the scheme of the present application will be further described below. It should be noted that, in the absence of conflict, the embodiments of the present application and the features therein can be combined with each other.

[0046] In the following description, many specific details are set forth to facilitate a full understanding of the present application, but the present application can also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present application, not all of the embodiments.

[0047] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprises" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a..." do not exclude the presence of other identical elements in the process, method, article or device that includes the elements.

[0048] As described in the background technology section, privilege escalation (i.e., switching a normal user to an administrator user) can be achieved through the su command or sudo command. However, the su command and sudo command are global privilege escalation tools and cannot limit the specific access or privilege escalation of a process. In other words, executable files such as su and sudo provide a comprehensive root privilege escalation solution at the system level (having root privileges is equivalent to having all permissions to the operating system). Even if a trusted program uses the su command or sudo command to elevate privileges, there is a risk that the program will abuse privileges to perform illegal operations, resulting in lower security of the operating system.

[0049] Therefore, in order to ensure the security of the operating system during the privilege escalation process, root permission management tools for upper-level applications are usually built into the user version (such as Magisk Manager, an application that can prompt the operating system administrator that a process is using root permissions and pop up a window to give a prompt). Specifically, when the root permission management tool detects that a process is performing a privilege escalation operation, it can prompt the operating system administrator which application or process is performing an operation that requires root permissions. After receiving the prompt, the administrator can decide whether to agree to the privilege escalation operation. However, in actual situations, the program may maliciously elevate permissions by disguising itself. Administrators usually cannot identify program disguises. Therefore, the security of the operating system cannot be effectively improved by using root permission management tools.

[0050] Furthermore, using root privilege management tools requires a high level of expertise from administrators, requiring strong identification skills. Furthermore, programs often execute scheduled tasks. Failure to promptly acknowledge prompts for privilege escalation operations can result in task failure. Therefore, using root privilege management tools cannot effectively manage the privilege escalation process.

[0051] Another method for escalating privileges is to root the entire operating system. This involves fully granting root permissions during the OS compilation process. This allows any application process to gain root permissions with almost no additional user intervention, similar to a debug version of a program. If a device uses a debug version compiled from source code, it is virtually impossible to control program permissions, allowing malicious programs to easily send shell commands to the underlying operating system, resulting in lower security.

[0052] In reality, whether the user rooted the entire device or the manufacturer provided the root version, the overall security of the operating system will be fundamentally damaged.

[0053] Thus, in order to solve the problems of the prior art, the embodiments of the present application provide a permission processing method, apparatus, device, storage medium and vehicle. The permission processing method can be applied to the scenario of elevating the rights of an application. Among them, the application can be an application in the client. Specifically, the permission processing method in the embodiments of the present application can be applied to the client-server (CS) architecture. The execution subject of the permission processing method can be the client.

[0054] The following first introduces the permission processing method provided in the embodiment of the present application.

[0055] Figure 1 FIG. 1 shows a flow chart of a permission processing method provided by an embodiment of the present application. Figure 1 As shown, the permission processing method provided in the embodiment of the present application includes the following steps:

[0056] S110: Obtain the target instruction and user information sent by the upper-layer application to the lower-layer authentication service, where the target permission corresponding to the target instruction is the administrator permission, and the target permission is greater than the application permission of the upper-layer application;

[0057] S120: Verify the user information through the underlying authentication service to obtain a verification result;

[0058] S130: If the verification result is passed, determine the target permission corresponding to the target instruction based on the correspondence between the instruction and the permission;

[0059] S140: Execute the target instruction according to the target authority.

[0060] In the permission processing method of the embodiment of the present application, since the target permission corresponding to the target instruction is the administrator permission, which is greater than the application permission of the upper-layer application, in order to be able to execute the target instruction, it is necessary to perform permission escalation processing on the process corresponding to the target instruction. By verifying the user information of the upper-layer application, and determining the target permission corresponding to the target instruction based on the correspondence between the instruction and the permission when the verification result is that the verification passes, the process executing the target instruction can be provided with limited administrator permissions instead of full administrator permissions. In this way, by executing the target instruction according to the target permission, the risk of the program abusing the permission to perform illegal operations can be avoided, thereby improving the security of the operating system.

[0061] The specific implementation methods of the above steps are introduced below.

[0062] In some embodiments, in S110, the target permission corresponding to the target instruction may be an administrator permission (i.e., root permission). The application permission of the upper-layer application may be an ordinary user permission. Since the target permission required to execute the target instruction is greater than the application permission of the upper-layer application, in order to enable the operating system to execute the target instruction issued by the upper-layer application, it is necessary to perform privilege escalation on the process corresponding to the target instruction. Among them, the privilege escalation method may be vertical privilege escalation. Vertical privilege escalation may be to enable a low-privilege user (such as an ordinary user) to obtain the permissions of a high-privilege user (such as an administrator user or a root user). Vertical privilege escalation can be achieved by exploiting security vulnerabilities, configuration errors, or design flaws in the system. In addition, the target instruction may be, for example, an iptables instruction for setting a gateway.

[0063] Additionally, user information can include digital certificates and token information. Digital certificates can be used to uniquely identify the identity of upper-layer applications. For example, digital certificates can be issued by a trusted Certificate Authority (CA). CA certificates play a crucial role in the digital certificate ecosystem, establishing a trusted chain and verifying the identity of individuals, websites, or organizations.

[0064] Based on this, in some embodiments, before the above S110, the following steps may also be included:

[0065] Configure digital certificates for upper-layer applications.

[0066] Token information can be user identity information generated by the authentication server when the login information of the upper-layer application is verified. The login information may include a username and password. The token information may include all information required for identity authentication. For example, username, password, permissions, signature, and other information. Specifically, the token information may be JWT (JSON Web Tokens) information. Since the verification process of JWT information requires checking whether the data and signature in the token information are valid, without the need to interact with the server that issued the token information, JWT information can be verified without a network connection.

[0067] Based on this, in some embodiments, before the above S110, the following steps may also be included:

[0068] Sending the login information to the authentication server so that the authentication server verifies the login information, and generating and sending token information to the client if the login information is successfully verified;

[0069] Receive the token information sent by the authentication server.

[0070] Here, the client can communicate with the authentication server using HTTPS. This communication may include the client sending login information to the authentication server and receiving token information from the authentication server. Furthermore, the login information can be used by the authentication server to authenticate the identity of upper-layer applications in the client. Specifically, the authentication server verifies the login information by matching the username and password in the login information. If the username and password match, the authentication is determined to be successful, and token information corresponding to the login information is generated.

[0071] Based on this, as an example, the client's operating system may include upper-layer applications and underlying services. The underlying services may include underlying authentication services. The underlying authentication service may be, for example, SSLSocketSevrver, referred to as socket service. Specifically, the user may first implement the source code of SSLSocketSevrver using C language, and then compile the source code of SSLSocketSevrver to generate an executable file. By running the program corresponding to the above executable file, the functions corresponding to the underlying authentication service may be implemented. During the initialization process of the operating system startup (for example, reading the init.rc file), the executable permission may be configured for the above executable file, and the boot permission may be configured. After the above executable file has the executable permission, the underlying authentication service (for example, the socket service) may receive the target instructions and user information issued by the upper-layer application.

[0072] Based on this, in order to ensure the accuracy of the target instruction and user information, in some embodiments, the above S110 may specifically include:

[0073] Obtain the target instructions and user information sent by the upper-layer application to the underlying authentication service through the Secure Sockets Layer protocol.

[0074] The Secure Sockets Layer (SSL) protocol is a security protocol that encrypts data using encryption algorithms, ensuring confidentiality. SSL also provides authentication mechanisms, ensuring that users are communicating with the intended server and not being redirected to a fraudulent site. Furthermore, SSL provides information integrity mechanisms, ensuring that data has not been altered during transmission.

[0075] In this way, the upper-layer application sends target instructions and user information to the underlying authentication service by using SSL communication, which can ensure the accuracy of the target instructions and user information.

[0076] In some embodiments, in S120, since the user information includes a digital certificate and token information, verifying the user information may include verifying the digital certificate and verifying the token information to obtain a verification result. The verification result may include verification pass and verification fail. If the verification result is verification fail, the underlying authentication service may refuse to execute the target instruction. If the verification result is verification pass, the underlying authentication service may perform subsequent operations to execute the target instruction. The verification process and verification results of the user information may be recorded locally on the client, or the verification tracking log may be uploaded to the cloud.

[0077] Based on this, in order to ensure the security and controllability of the privilege escalation process, in some embodiments, the above S120 may specifically include:

[0078] Verify the digital certificate and obtain the certificate verification result;

[0079] Verify the token information and obtain the token verification result;

[0080] The verification result is determined based on the certificate verification result and the token verification result.

[0081] Here, the underlying authentication service can verify the legitimacy of the digital certificate (such as a CA certificate). Specifically, the underlying authentication service can verify whether the issuer, validity period, purpose, and other information of the digital certificate are legal, and verify whether the digital signature on the digital certificate is correct. If all of the above content is verified, it can be determined that the certificate verification result is successful. If any of the above content is not verified, it can be determined that the certificate verification result is not verified and failed.

[0082] The underlying authentication service can also verify the token information (such as JWT information). Verification of the token information can include verification of the device identification, expiration time, and identity information in the token information. The specific process of verifying the token information can refer to the existing methods and will not be described in detail here. If multiple contents in the token information are verified, it can be determined that the token verification result is successful. If one item in the token information fails to pass the verification, it can be determined that the token verification result is a verification failure.

[0083] If both the certificate verification result and the token verification result are verification passed, the verification result may be verification passed. If at least one of the certificate verification result and the token verification result is verification failed, the verification result may be verification failed.

[0084] In this way, by double-checking the digital certificate and token information, the security and controllability of the privilege escalation process can be guaranteed.

[0085] In some embodiments, in S130, the permission may be a portion of the administrator permissions (i.e., root permissions) required to execute the instruction, rather than all administrator permissions. Based on this, the target permission may be the portion of the administrator permissions required to execute the target instruction. In addition, the correspondence between instructions and permissions can be pre-set.

[0086] Based on this, in order to improve the security of the operating system, in some embodiments, before the above S130, the following steps may be further included:

[0087] Set the correspondence between instructions and permissions in the permission configuration file;

[0088] Add a rights profile to the executable file corresponding to the underlying authentication service.

[0089] Based on this, the above S130 may specifically include:

[0090] Through the underlying authentication service, the target permission corresponding to the target instruction is determined based on the correspondence between instructions and permissions.

[0091] Here, the permission profile may be, for example, a Security-Enhanced Linux (SELinux) te profile. SELinux is a mandatory access control security mechanism integrated into the Linux operating system to enhance the security of the Linux system. SELinux's main functions and features include mandatory access control (MAC), the principle of least privilege, security policy customization, isolation and protection of system services, and prevention of unauthorized data access.

[0092] Since the main principle of SELinux is the principle of least privilege, by setting the correspondence between instructions and permissions in the SELinux te configuration file (for example, adding the SELinux permissions required for iptables to set up the gateway to the te configuration file), administrator permissions can be broken down into smaller sub-permissions, allowing upper-level applications to use sub-permissions applied for in advance without exceeding the boundaries and escalating permissions.

[0093] In this way, by adding the permission configuration file to the executable file corresponding to the underlying authentication service, and then determining the target permission through the underlying authentication service based on the SELinux te configuration file, it is possible to ensure that the target permission is the minimum permission to execute the target instruction, that is, it is possible to open some relevant permissions for the specific business of the upper-level application, thereby avoiding the risk of programs abusing permissions to perform illegal operations and improving the security of the operating system.

[0094] In some embodiments, in S140, after determining the target instruction, the underlying authentication service may proceed with issuing the instruction to the operating system. The operating system may execute the target instruction according to the target permissions, obtain an execution result, and send the execution result to the underlying authentication service. The underlying authentication service may return the execution result to the upper-layer application with which it communicates.

[0095] In order to better describe the entire solution, some specific examples are given based on the above embodiments.

[0096] For example, Figure 2 As shown, the permission processing method provided in the embodiment of the present application may include the following steps:

[0097] S21. The client sends the login information of the upper-layer application to the authentication server;

[0098] S22. The authentication server authenticates the login information and generates JWT information if the authentication is successful.

[0099] S23. The authentication server sends JWT information to the client;

[0100] S24. The upper-layer application in the client sends a target instruction and user information to the SSLSocketSevrver through SSL communication. The user information includes JWT information and CA certificate.

[0101] S25, SSLSocketSevrver verifies the user information;

[0102] S26, determine whether the verification is passed, if so, execute S27, if not, execute S29;

[0103] S27. Obtain the target permission corresponding to the target instruction;

[0104] S28. Execute the target instruction according to the target authority, obtain and return the execution result to the upper-level application;

[0105] S29. Refuse to execute the target instruction.

[0106] The embodiments of the present application provide a safe and reliable way to elevate privileges for applications from the perspective of system design. Specifically, on the one hand, the root privilege is not directly open to any upper-layer application, and all processes that require root privileges can only issue instructions with the help of the underlying SSLSocketSevrver (i.e., socket service). On the other hand, the underlying socket service is designed to provide only limited root privilege capabilities for each process. On the other hand, all privilege escalation processes are designed to be recorded and tracked. In this way, as described above, the security of the operating system can be guaranteed during the privilege escalation process.

[0107] Based on the permission processing method provided in the above embodiment, this application also provides a specific implementation of a permission processing device. Please refer to the following embodiment.

[0108] like Figure 3 As shown, the permission processing device 300 provided in this embodiment of the application includes the following modules:

[0109] An acquisition module 310 is configured to acquire a target instruction and user information sent by an upper-layer application to a lower-layer authentication service. The target instruction corresponds to an administrator's permission, which is greater than the application permission of the upper-layer application.

[0110] Verification module 320, used to verify user information through the underlying authentication service and obtain a verification result;

[0111] A determination module 330 is configured to determine a target permission corresponding to the target instruction based on a correspondence between instructions and permissions when the verification result is that the verification passes;

[0112] The execution module 340 is configured to execute target instructions according to target permissions.

[0113] The following is a detailed description of the above-mentioned permission processing device 300, as shown below:

[0114] In some embodiments, the permission processing apparatus 300 may further include:

[0115] A setting module, configured to set the correspondence between instructions and permissions in a permissions configuration file before determining a target permission corresponding to a target instruction based on the correspondence between instructions and permissions;

[0116] Adds a module for adding permission profiles to the executable file corresponding to the underlying authentication service.

[0117] Based on this, the determination module 330 may specifically include:

[0118] The first determination submodule is used to determine the target permission corresponding to the target instruction according to the corresponding relationship between the instruction and the permission through the underlying authentication service.

[0119] In some embodiments, the acquisition module 310 may specifically include:

[0120] The acquisition submodule is used to obtain the target instructions and user information sent by the upper-layer application to the underlying authentication service through the Secure Sockets Layer protocol.

[0121] In some embodiments, the user information includes a digital certificate and token information. The digital certificate is used to uniquely identify the identity of the upper-layer application, and the token information is the user identity information generated by the authentication server when the login information of the upper-layer application is verified.

[0122] Based on this, the verification module 320 may specifically include:

[0123] The first verification submodule is used to verify the digital certificate and obtain a certificate verification result;

[0124] The second verification submodule is used to verify the token information and obtain the token verification result;

[0125] The second determining submodule is configured to determine a verification result according to the certificate verification result and the token verification result.

[0126] In some embodiments, the permission processing apparatus 300 may further include:

[0127] The sending module is used to send login information to the authentication server before obtaining the target instruction and user information sent by the upper-layer application to the lower-layer authentication service, so that the authentication server can verify the login information, and generate and send token information to the client if the login information is verified successfully;

[0128] The receiving module is used to receive the token information sent by the authentication server.

[0129] In some embodiments, the permission processing apparatus 300 may further include:

[0130] The configuration module is used to configure a digital certificate for the upper-layer application before obtaining the target instructions and user information sent by the upper-layer application to the lower-layer authentication service.

[0131] In the permission processing device of the embodiment of the present application, since the target permission corresponding to the target instruction is the administrator permission, which is greater than the application permission of the upper-layer application, in order to be able to execute the target instruction, it is necessary to perform permission escalation processing on the process corresponding to the target instruction. By verifying the user information of the upper-layer application, and determining the target permission corresponding to the target instruction based on the correspondence between the instruction and the permission when the verification result is that the verification passes, the process executing the target instruction can be provided with limited administrator permissions instead of full administrator permissions. In this way, by executing the target instruction according to the target permission, the risk of the program abusing the permission to perform illegal operations can be avoided, thereby improving the security of the operating system.

[0132] Based on the permission processing method provided in the above embodiment, the embodiment of the present application also provides a specific implementation of the electronic device. Figure 4 A schematic diagram of an electronic device 400 provided in an embodiment of the present application is shown.

[0133] The electronic device 400 may include a processor 410 and a memory 420 storing computer program instructions.

[0134] Specifically, the processor 410 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0135] Memory 420 may include a large capacity memory for data or instructions. By way of example and not limitation, memory 420 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 420 may include removable or non-removable (or fixed) media. Where appropriate, memory 420 may be internal or external to electronic device 400. In a particular embodiment, memory 420 is a non-volatile solid-state memory.

[0136] The memory may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Thus, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of the present application.

[0137] The processor 410 implements any one of the permission processing methods in the above embodiments by reading and executing computer program instructions stored in the memory 420 .

[0138] In one example, the electronic device 400 may further include a communication interface 430 and a bus 440. Figure 4 As shown, the processor 410 , the memory 420 , and the communication interface 430 are connected via a bus 440 and communicate with each other.

[0139] The communication interface 430 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0140] Bus 440 comprises hardware, software or both, couples the parts of electronic equipment to each other.For example, and not limitation, bus can comprise accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations.In suitable cases, bus 440 can comprise one or more buses.Although the present application embodiment describes and shows specific bus, the application considers any suitable bus or interconnection.

[0141] Illustratively, the electronic device 400 may be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, an ultra-mobile personal computer (UMPC), a netbook, or a personal digital assistant (PDA).

[0142] The electronic device can execute the permission processing method in the embodiment of the present application, thereby realizing the combination Figures 1 to 3 Described permission processing method and device.

[0143] In addition, in conjunction with the permission processing methods in the above embodiments, embodiments of the present application may provide a computer-readable storage medium for implementation. The computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any one of the permission processing methods in the above embodiments is implemented.

[0144] In addition, an embodiment of the present application further provides a vehicle, which may include at least one of the following:

[0145] The rights processing device according to any one of the embodiments of the second aspect;

[0146] The electronic device according to any one of the embodiments of the third aspect;

[0147] As the computer-readable storage medium in any embodiment of the fourth aspect, no further details will be given here.

[0148] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0149] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROMs, flash memories, erasable ROMs (EROMs), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0150] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps. In other words, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0151] Aspects of the present application have been described above with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed via the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. This processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It is also understood that each box in the block diagram and / or the flowchart and the combination of the boxes in the block diagram and / or the flowchart can also be implemented by the dedicated hardware that performs the specified function or action, or can be implemented by the combination of dedicated hardware and computer instructions.

[0152] The above description is only a specific embodiment of the present application. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the scope of protection of the present application.

Claims

1. A permission processing method, characterized in that: include: Obtaining the target instruction and user information sent by the upper-layer application to the underlying authentication service, wherein the target permission corresponding to the target instruction is the administrator permission, and the target permission is greater than the application permission of the upper-layer application; Verify the user information through the underlying authentication service to obtain a verification result; If the verification result is that the verification passes, determining the target permission corresponding to the target instruction according to the correspondence between instructions and permissions; Execute the target instruction according to the target permission.

2. The method according to claim 1, characterized in that Before determining the target permission corresponding to the target instruction according to the correspondence between the instruction and the permission, the method further includes: Setting a correspondence between the instruction and the permission in a permission configuration file; Adding the rights configuration file to the executable file corresponding to the underlying authentication service; The determining the target permission corresponding to the target instruction according to the correspondence between the instruction and the permission includes: The target permission corresponding to the target instruction is determined according to the corresponding relationship between the instruction and the permission through the underlying authentication service.

3. The method according to claim 1, characterized in that The step of obtaining target instructions and user information sent by the upper layer application to the lower layer authentication service includes: The target instruction and the user information sent by the upper layer application to the underlying authentication service through the secure socket layer protocol are obtained.

4. The method according to claim 1, wherein The user information includes a digital certificate and token information, wherein the digital certificate is used to uniquely identify the identity of the upper-layer application, and the token information is user identity information generated by the authentication server when the login information of the upper-layer application is verified; The verifying the user information to obtain a verification result includes: Verifying the digital certificate to obtain a certificate verification result; Verifying the token information to obtain a token verification result; The verification result is determined according to the certificate verification result and the token verification result.

5. The method according to claim 4, characterized in that Before obtaining the target instruction and user information sent by the upper layer application to the lower layer authentication service, the method further includes: Sending the login information to the authentication server so that the authentication server verifies the login information, and generating and sending the token information to the client if the login information is successfully verified; Receive the token information sent by the authentication server.

6. The method according to claim 4, characterized in that Before obtaining the target instruction and user information sent by the upper layer application to the lower layer authentication service, the method further includes: The digital certificate is configured for the upper-layer application.

7. A rights processing device, characterized in that: The device comprises: An acquisition module is used to obtain a target instruction and user information sent by an upper-layer application to a lower-layer authentication service, wherein the target permission corresponding to the target instruction is an administrator permission, and the target permission is greater than the application permission of the upper-layer application; A verification module, configured to verify the user information through the underlying authentication service and obtain a verification result; a determination module, configured to determine, if the verification result is a passed verification, the target permission corresponding to the target instruction based on the correspondence between instructions and permissions; An execution module is used to execute the target instruction according to the target permission.

8. An electronic device, characterized in that: The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the permission processing method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the permission processing method according to any one of claims 1 to 6 is implemented.

10. A vehicle, characterized in that: Include at least one of the following: The rights processing device according to claim 7; The electronic device according to claim 8; The computer-readable storage medium of claim 9.

Images