CN104346559A - Authority request response method and device thereof - Google Patents

Abstract

Taking the Android application scene as an example, the present invention discloses a permission request response method, which includes the following steps: starting a communication interface belonging to the system level, and monitoring external permission requests through the communication interface; obtaining the characteristic identification of the requesting party according to the permission request, and then Check whether the feature identifier is in the allowed state from the preset authentication list; when the feature identifier is in the allowed state, apply for permission to the system for the permission request. The authority request management function realized by means of the present invention has the characteristics of fast and efficient communication, safe and reliable technology.

Description

Permission request response method and corresponding device

technical field

The invention relates to the rights management technology of a computer operating system, in particular to a method for responding to a rights request and a corresponding device.

Background technique

Based on the operating system born from Uinux, from the Linux series to the Android operating system of mobile terminals, there are strict user management mechanisms. Among them, taking Android as an example, the highest authority account of the system is Root, and the authority of this account also represents the highest level of the authority management mechanism, which can start or stop a process, delete or add users, add or disable hardware, and so on. When the mobile terminal device leaves the factory, the manufacturer generally does not open the Root authority to the user for security reasons. In this case, when the system operation performed by the user on the mobile terminal device, or when a third-party application such as mobile phone security software needs to implement certain functions such as uninstalling the factory application, it will be hindered. Therefore, obtaining Root privileges has become more and more common.

Mobile phone security software currently on the market, such as "360 Mobile Assistant", is usually equipped with a rights management module for mobile phone applications. After obtaining Root permission, it is necessary to further strengthen the management of permission requests, so as to realize the security monitoring of the operating system and prevent malicious applications from achieving their own purposes at will, such as requesting contact permissions, requesting mobile phone IMEI permissions, etc., so as to give users Greater freedom of operation, but also to ensure technical safety.

Existing technology has realized Root authority management to a large extent, but also has following deficiency: on the one hand, because the communication mechanism that carries out authority management is not utilized well, causes the efficiency of Root authority management not high; On the other hand, excessive Depending on the function of the system, the operating efficiency of rights management is not high.

Contents of the invention

The object of the present invention is to provide a permission request response method with relatively high operating efficiency and a corresponding device.

For realizing the purpose of the present invention, the present invention takes following technical scheme:

A permission request response method provided by the present invention includes the following steps:

Start the communication interface belonging to the system level, and monitor external permission requests through the communication interface;

Obtain the requester's feature ID according to the permission request, and check whether the feature ID is allowed in the preset authentication list;

When the feature is identified as being allowed, apply for permission to the system for the permission request.

Preferably, the system-level communication interface refers to a communication service process established based on Android's Binder mechanism, which is used to communicate with an external application process that initiates a permission request.

Preferably, the feature identifier refers to a UID in the Android system, and each UID corresponds to an application.

According to an embodiment of the present invention, the preset authentication list stores several feature identifiers, and the presence of a feature identifier in the authentication list indicates that the feature identifier is in an allowed state.

According to another embodiment of the present invention, the preset authentication list stores several feature identifiers and a state identification field corresponding to each feature identifier. When the corresponding state identification field of a certain feature identifier is set to represent When the symbol is allowed, the symbol is used to represent the feature flag as the allowed state.

Further, when the feature identification is in a non-allowed state, deny the permission request.

Preferably, the method comprises the further step of obtaining public authentication list data from a remote interface and updating said authentication list locally.

Further, when the permission request is used to successfully obtain the Root permission, the communication between the user process that initiates the permission request and the service process is bound, and the service process is used to execute the instruction requested by the user process in response.

Preferably, the local authentication list is provided with a type identifier used to characterize the authorization period of the user program corresponding to the feature identifier, and when applying for authorization to the system, apply for different types of authorization corresponding to the type identifier. authority.

A permission request response device provided by the present invention includes:

The communication interface is activated at the system level and is used to monitor external permission requests;

A retrieval unit, configured to obtain the characteristic identifier of the requesting party according to the permission request, and retrieve whether the characteristic identifier is in a permitted state in the preset authentication list;

The processing unit is configured to apply for permission to the system for the permission request when the feature identifier is in an allowed state.

Specifically, the communication interface is a system-level communication service process established based on the Android Binder mechanism, and obtains the permission request by communicating with an external application process.

Preferably, the feature identifier refers to a UID in the Android system, and each UID corresponds to an application.

According to an embodiment of the present invention, the preset authentication list is used to store several feature identifiers, and the existence of a feature identifier in the authentication list indicates that the feature identifier is allowed.

According to another embodiment of the present invention, the preset authentication list is used to store several feature identifiers and a state identification field corresponding to each feature identifier. When the corresponding state identification field of a certain feature identifier is When it is set as a symbol that is allowed, the symbol is used to represent the feature flag as the allowed state.

Further, the processing unit is configured to reject the permission request when the feature identifier is in an unallowed state.

Preferably, the present invention comprises a maintenance unit for obtaining public authentication list data from a remote interface and updating said authentication list locally.

Further, the device also includes a service process, which binds and communicates with the user process that initiates the permission request after the root permission is successfully obtained by using the permission request, and the service process is used to execute instructions requested by the user process in response.

Preferably, the local authentication list is provided with a type identifier used to characterize the authorization period of the user program corresponding to the feature identifier, and when applying for authorization to the system, apply for different types of authorization corresponding to the type identifier. authority.

Compared with the prior art, the present invention has at least the following advantages: the present invention uses a system-level communication interface as the basis to establish a permission management mechanism based on permission requests from external applications, which has the advantages of fast communication and high success rate. Further, by establishing The preset authentication list can realize independent management of permission requests for external applications. From a technical point of view, this authentication list has the function similar to a firewall, and has the advantages of data concentration, efficient operation, safety and reliability.

Additional aspects and advantages of the invention will be set forth in part in the description which follows, and will become apparent from the description, or may be learned by practice of the invention.

Description of drawings

The above and/or additional aspects and advantages of the present invention will become apparent and easy to understand from the following description of the embodiments in conjunction with the accompanying drawings, wherein:

Fig. 1 is a functional block diagram of the permission request response method of the present invention;

Fig. 2 is a functional block diagram of the permission request responding device of the present invention.

Detailed ways

Embodiments of the present invention are described in detail below, examples of which are shown in the drawings, wherein the same or similar reference numerals designate the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the figures are exemplary only for explaining the present invention and should not be construed as limiting the present invention.

Those skilled in the art will understand that unless otherwise stated, the singular forms "a", "an", "said" and "the" used herein may also include plural forms. It should be further understood that the word "comprising" used in the description of the present invention refers to the presence of said features, integers, steps, operations, elements and/or components, but does not exclude the presence or addition of one or more other features, Integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Additionally, "connected" or "coupled" as used herein may include wireless connection or wireless coupling. The expression "and/or" used herein includes all or any elements and all combinations of one or more associated listed items.

Those skilled in the art can understand that, unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art to which this invention belongs. It should also be understood that terms, such as those defined in commonly used dictionaries, should be understood to have meanings consistent with their meaning in the context of the prior art, and unless specifically defined as herein, are not intended to be idealized or overly Formal meaning to explain.

Those skilled in the art can understand that the "terminal" and "terminal equipment" used here not only include wireless signal receiver equipment, which only has wireless signal receiver equipment without transmission capabilities, but also include receiving and transmitting hardware. A device having receiving and transmitting hardware capable of performing bi-directional communication over a bi-directional communication link. Such equipment may include: cellular or other communication equipment, which has a single-line display or a multi-line display or a cellular or other communication equipment without a multi-line display; PCS (Personal Communications Service, personal communication system), which can combine voice, data Processing, facsimile and/or data communication capabilities; PDA (Personal Digital Assistant, Personal Digital Assistant), which may include radio frequency receiver, pager, Internet/Intranet access, web browser, notepad, calendar and/or GPS (Global Positioning System , Global Positioning System) receiver; a conventional laptop and/or palmtop computer or other device having and/or including a radio frequency receiver. As used herein, a "terminal", "terminal device" may be portable, transportable, installed in a vehicle (air, sea, and/or land), or adapted and/or configured to operate locally, and/or In distributed form, the operation operates at any other location on Earth and/or in space. The "terminal" and "terminal device" used here can also be a communication terminal, an Internet terminal, a music/video player terminal, such as a PDA, a MID (Mobile Internet Device, a mobile Internet device) and/or a music/video player Functional mobile phones, smart TVs, set-top boxes and other devices.

Those skilled in the art can understand that the concepts of server, cloud, and remote network equipment used here have equivalent effects, including but not limited to computers, network hosts, single network servers, multiple network server sets, or multiple servers. Composed of clouds. Here, the cloud is composed of a large number of computers or network servers based on cloud computing (Cloud Computing), where cloud computing is a type of distributed computing, a super virtual computer composed of a group of loosely coupled computer sets. In the embodiment of the present invention, the communication between the remote network equipment, the terminal equipment and the WNS server can be realized through any communication method, including but not limited to, mobile communication based on 3GPP, LTE, WIMAX, based on TCP/IP, UDP protocol Computer network communication and short-distance wireless transmission methods based on Bluetooth and infrared transmission standards.

Those skilled in the art should understand that the concepts of "application", "application program", "application software" and similar expressions referred to in the present invention are the same concepts well known to those skilled in the art, and refer to a series of computer instructions and related Computer software that is organically constructed from data resources and suitable for electronic operation. Unless otherwise specified, this naming itself is not limited by the type of programming language, level, or the operating system or platform on which it runs. Naturally, such concepts are also not limited by any form of terminal.

The application scene of the permission request response method of the present invention is realized in the operating system environment based on the Unix system. In order to implement this method, it is necessary to instantiate this method into an application program, obtain Root authority, install and run it on a relevant operating system.

As we all know, Root authority refers to the system administrator authority of Unix-like operating systems (including Linux, Android), similar to the Administrator (administrator) authority in Windows (Windows) system; Root authority can access and modify almost All files (Android system files and user files, excluding ROM). However, because the current mobile terminal system is very strict about the management of Root permissions, most applications or programs do not have Root permissions usually, so some operations that require Root permissions cannot be performed, such as installing or uninstalling applications, etc. At the same time, the calling process of this type of operation needs to apply for root permission from the system every time it performs the corresponding operation, but if other application processes are using the root permission to perform related operations at this time, the root permission application of the calling process cannot be successful; What's more, if the user sets the operation of disabling the Root permission in the system, the relevant calling process cannot perform the relevant operation. Based on this, the present invention only needs to send a Root permission acquisition request to the system, specifically, the SU (Super User, super user) command built into the system can be called to obtain the Root permission, or the shell with the Root permission can be obtained to obtain the Root permission and in the system. Start the process in the shell, and then after obtaining the Root authority authorization of the system, it is not necessary to repeatedly apply for Root authority when other subsequent calling processes need to perform related operations; the specific Root authority acquisition process can refer to the Root authority call function of the prior art , the present invention will not be described in detail here. Based on the foregoing prior knowledge, the permission request response method of the present invention will be disclosed in detail below in conjunction with FIG. 1 . The method comprises the steps of:

S11. Start a communication interface belonging to the system level, and monitor external authority requests through the communication interface:

The communication interface referred to in this embodiment refers to a program module implemented by this method running in the memory, and registering a communication service with the system after the corresponding main process in the memory realizes the above-mentioned power escalation operation process. Taking Android as an example, the communication service process is based on the Binder mechanism provided by the Android system, registers itself with the System Manager, and establishes a C/S architecture between the communication service process and the external application process it monitors through the inherent Binder mechanism provided by Android. communication channels. Specifically, after obtaining the Root authority of the system, in order to facilitate subsequent monitoring of external application processes and related operating functions, the present invention first starts the main process that has obtained the Root authority and is instantiated and run by this method , insert the communication service process in the system through the main process, for example, the insertion operation can be realized by calling the function ServiceManager. Memory, and the communication service process established by it also becomes a system-level communication interface. It should be noted that the communication service process has become a system-level service process level through the above configuration, and its authority is obviously higher than that of other external application processes or even the main process and other processes that call it. Therefore, the communication service process can be used as a communication basis to provide communication guarantee for other processes that call it, and complete the communication connection between the system and other processes that call it. It can be further deduced from this that any other client that complies with the communication specification of the communication interface of the present invention can communicate with the communication interface of the present invention through the Binder mechanism to obtain corresponding permissions.

Therefore, the communication interface described in this embodiment is represented as the communication service process, and its function is to realize the Binder communication between the main process and the external application process. This communication mode has the characteristics of fast and stable. For the core gist of this method, the communication service process is mainly used to monitor the permission request initiated by the external application process, and this permission request generally refers to a request for escalation of authority that is expected to obtain Root permission to achieve deep access to system resources . For this method, except that the communication service process can be used to establish a communication interface, of course, other different functions can also be realized through other processes, and these other processes can communicate with external application processes by means of the communication service process. Communication, so as to complete other special operation instructions through combination of internal and external. For example, these other processes may perform one or more of the following operations, and are not limited here: perform uninstallation of preset applications, perform installation or uninstallation of application programs, perform backup or restoration of application data, perform Enable or disable etc.

After the above communication interface becomes the basis of inter-process communication, it can monitor the external application process. When the external application process needs to obtain the Root authority, it will send a permission request to the system to obtain the Root authority. The communication service process is due to its At a higher level, this user request can be obtained and processed with priority. After the communication service process obtains the permission request, it can submit it to the main process of the present invention, and the main process will do further processing.

S12. According to the permission request, obtain the characteristic identifier of the requesting party, and search whether the characteristic identifier is in the allowed state in the preset authentication list:

As we all know, the definition of UID (User Identifier, User Identifier) in the Android system is a specific identification symbol for each specific application and has unique characteristics. Therefore, UID is the unique characteristic identification of each specific application. In this embodiment, the main process implemented by this method can obtain the feature identifier of the external application program process from the permission request of the process of the external application program forwarded by the communication interface, and can further identify the corresponding application, and decide whether to respond to the open permission request.

In this step, the main process for realizing this step is also responsible for maintaining an authentication list. The certification list can be implemented in various forms, and the difference between various forms is mainly reflected in its internal mapping relationship. The following two forms are listed for reference:

A. You can only store the UID of each application that is allowed to obtain Root permission by default. Therefore, the application corresponding to the feature identifier that enters the authentication list is regarded as a request to obtain Root permission and is in an allowed state. , will be satisfied.

B. A state identification field can be added to the authentication list of scheme A, and a state identification character is mapped to each characteristic identification. For example, when the state identification character of the record where a certain UID is located is "Y", it represents the UID The corresponding permission request is in the allowed state; when it is "N", it indicates that the permission request corresponding to the UID is not in the allowed state.

In addition to the above two ways to implement the authentication list, in order to facilitate process scheduling, the process identification PID can be further added, and the corresponding PID can be obtained from it during the life cycle of the main process and when the external application program sends the permission request for the first time , stored in the authentication list, for comparison and use when the external application process initiates a permission request next time, and the permission status of the permission request is jointly determined by the PID and UID. In this way, permission request management can be further refined to sub-processes of external applications.

After the main process implemented with this method receives the permission request forwarded by the communication interface, it extracts the UID (and PID, the same below), and then uses the UID to retrieve it from the authentication list. When the UID exists, it can be confirmed that the permission request corresponding to the UID should be allowed. If there is no corresponding UID in the authentication list, it means that the UID is not allowed; for method B, when the UID exists in the authentication list and its When the status identifier of the status identifier field is "Y", it indicates that the permission request corresponding to the UID should be allowed; otherwise, when the status identifier is "N", it indicates that the permission request corresponding to the UID is not allowed.

It can be seen that by adopting the authentication list of the present invention, by starting the service process with Root authority after obtaining the system Root authority and inserting the communication service process into the system, the external application process that calls the communication service process can perform corresponding operations without repeating Apply for Root permission, and the corresponding operation can be performed through the started main process, which effectively avoids the operation failure caused by the Root permission being used or disabled, and thus greatly improves the efficiency of data communication.

The acquisition of the original data in the authentication list may be generated according to the user's usage habits during the historical use of the method. For example, for the first time, the user gives a subjective indication to allow it to obtain the Root permission for the request of an external application process, that is, it is added to the authentication list by the main process of the present invention and marked as a state of being allowed to obtain the corresponding permission. You can avoid pop-up window inquiries. The authentication list can also be maintained remotely, by calling the remote communication interface through the main process, and downloading the latest authentication list data from the cloud regularly or irregularly, so as to update the local authentication list, thereby taking advantage of big data , making the data in the authentication list more secure.

To adapt to the above situation, the cloud maintains a public authentication list, and the main process of the program installed with the method of the present invention uploads the data of whether the user is allowed to obtain permission or not for each program UID, and then according to the statistical method for each UID Statistically, when most users, for example 60%, allow a certain UID to obtain Root authority, mark the status identifier corresponding to the UID as "Y", otherwise, mark it as "N". The local master process downloads the public authentication list through the remote interface, compares it with the local authentication list, and adds new records in the public authentication list to the local authentication list on the basis of respecting the user's subjective instructions. Of course, for the sake of safety, pop-up queries can be made for records with the same UID but different states in the two tables to see if the user adopts the data of the public authentication list. If the user chooses yes, the UID related to the public authentication list The record replaces the corresponding record in the local authentication list, if not, the subsequent operation is discarded. It can be seen that the dynamic maintenance of the authentication list can be realized in this way, so that the authentication list can greatly play its security role from the perspective of technical implementation.

It can be understood that the form of the public authentication list maintained by the cloud should not be limited to the field information of the UID and PID, and can be further extended to add the signature information of the program or service that invokes the communication service process, so that the communication service process can Further, by verifying the signature information of the program or service that initiated the permission request, it is determined whether to open Root permission for it, and its security protection effect is strengthened.

It should be pointed out that the storage form of the authentication list can be a linked list in memory, or a database or a text file stored locally, which can be flexibly implemented by those skilled in the art.

S13. When the feature identifier is in an allowed state, apply for permission to the system for the permission request.

Through the implementation of the previous step, it can be judged whether a permission request is the corresponding feature identification is allowed state, if so, then the main process realized by the present invention can be released for the permission request, and the Root of the permission request system Permission, the system grants Root permission to the corresponding external application process. And if the result obtained in the previous step is that the corresponding feature identification is not allowed, then the main process can reject the permission request, and return a false message to the external application process through its communication interface, so that the permission request issued by the external application process return without success; or, directly return a reply that the permission request is unsuccessful.

Through the above method of responding to the authority request of the present invention, a more efficient authority management mechanism can be realized, which not only ensures faster and more effective communication between processes, but also at the technical level, through the role of the authentication list, the authority can also be made Management is safer.

Correspondingly, the present invention can provide a permission request responding device according to the aforementioned method, and each step of the method can be realized by means of each module realized by the device, and corresponding functions can also be realized. The device can be implemented centrally in the form of logic functions on the processor. Please refer to FIG. 2 , specifically, the permission request response device provided by the present invention includes a communication interface 11 , a retrieval unit 12 and a processing unit 13 .

The communication interface 11 is constructed by a communication service process running in the memory, which is implemented by registering a communication service process with the system after the corresponding main process in the memory realizes the privilege escalation operation as mentioned above. Taking Android as an example, the communication service process is based on the Binder mechanism provided by the Android system, registers itself with the System Manager, and establishes a C/S architecture between the communication service process and the external application process it monitors through the inherent Binder mechanism provided by Android. The communication channel, the communication service process forms the communication interface 11. Specifically, after obtaining the Root authority of the system, in order to facilitate subsequent monitoring of external application processes and related operating functions, the present invention inserts the communication service process into the system through a main process, for example, through the system call function ServiceManager.addService is used to implement the insert operation, so that not only the main process can be resident in memory, but also the communication service process established by it can also become the communication interface 11 at the system level. It should be noted that the communication service process has become a system-level service process level through the above configuration, and its authority is obviously higher than that of other external application processes or even the main process and other processes that call it. Therefore, the communication service process can be used as a communication basis to provide communication guarantee for other processes that call it, and complete the communication connection between the system and other processes that call it.

Therefore, the communication interface 11 in this embodiment is represented as the communication service process, and its function is to realize the Binder communication between the main process and the external application process. This communication method has the characteristics of fast and stable. As far as the core gist of this device is concerned, the communication service process is mainly used to monitor permission requests initiated by external application processes. This permission request generally refers to a request for privilege escalation that is expected to obtain Root permission to achieve deep access to system resources. . For this device, except that the communication service process can be used to establish the communication interface 11, of course, other processes can also be used to realize other different functions, and these other processes can communicate with the external application process by means of the communication service process. Communication, so as to complete other special operation instructions through combination of internal and external. For example, these other processes may perform one or more of the following operations, and are not limited here: perform uninstallation of preset applications, perform installation or uninstallation of application programs, perform backup or restoration of application data, perform Enable or disable, etc., perform memory cleaning functions, etc.

After the communication interface 11 becomes the basis of inter-process communication, it can realize the monitoring of the external application process. When the external application process needs to obtain the Root authority, it will send a permission request to the system to obtain the Root authority. The communication service process is due to It is at a higher level, so it can obtain and process this user request first. After the communication service process obtains the permission request, it can submit it to the main process of the present invention, and the main process will do further processing.

The retrieval unit 12 is configured to obtain the requester's characteristic identifier according to the permission request, and retrieve whether the characteristic identifier is in a permitted state in the preset authentication list.

As we all know, the definition of UID (User Identifier, User Identifier) in the Android system is a specific identification symbol for each specific application and has unique characteristics. Therefore, UID is the unique characteristic identification of each specific application. In this embodiment, the main process implemented by this device can obtain the characteristic identifier of the external application program process from the permission request of the process originating from the external application program forwarded by the communication interface 11, and can further identify the corresponding application and decide whether to respond to the open permission request.

In the retrieval unit 12, the main process for realizing the retrieval unit 12 is also responsible for maintaining an authentication list, based on which a maintenance unit (not shown) is constructed to maintain the authentication list. Logically, the maintenance unit can be integrated with the retrieval unit 12, or can be independent of each other. The certification list can be implemented in various forms, and the difference between various forms is mainly reflected in its internal mapping relationship. The following two forms are listed for reference:

A. You can only store the UID of each application that is allowed to obtain Root permission by default. Therefore, the application corresponding to the feature identifier that enters the authentication list is regarded as a request to obtain Root permission and is in an allowed state. , will be satisfied.

B. A state identification field can be added to the authentication list of scheme A, and a state identification character is mapped to each characteristic identification. For example, when the state identification character of the record where a certain UID is located is "Y", it represents the UID The corresponding permission request is in the allowed state; when it is "N", it indicates that the permission request corresponding to the UID is not in the allowed state.

In addition to the above two ways to implement the authentication list, in order to facilitate process scheduling, the process identification PID can be further added, and the corresponding PID can be obtained from it during the life cycle of the main process and when the external application program sends the permission request for the first time , stored in the authentication list, for comparison and use when the external application process initiates a permission request next time, and the permission status of the permission request is jointly determined by the PID and UID. In this way, permission request management can be further refined to sub-processes of external applications.

After the main process implemented with this device receives the permission request forwarded by the communication interface 11, it extracts the UID (and PID, the same below), and then uses the UID to retrieve the authentication list. For mode A, when the authentication list When the UID exists in the UID, it can be confirmed that the permission request corresponding to the UID should be allowed. If there is no corresponding UID in the authentication list, it means that the UID is not allowed; for method B, when the UID exists in the authentication list and When the status identifier of the status identifier field is "Y", it indicates that the permission request corresponding to the UID should be allowed; otherwise, when the status identifier is "N", it indicates that the permission request corresponding to the UID is not allowed.

It can be seen that by adopting the authentication list of the present invention, by starting the service process with Root authority after obtaining the system Root authority and inserting the communication service process into the system, the external application process that calls the communication service process can perform corresponding operations without repeating Apply for Root permission, and the corresponding operation can be performed through the started main process, which effectively avoids the operation failure caused by the Root permission being used or disabled, and thus greatly improves the efficiency of data communication.

The maintenance of the authentication list is realized by the maintenance unit, including how to make the authentication list form basic data and how to update the data therein.

The acquisition of the original data in the authentication list may be generated according to the usage habits of the user during the historical use of the device. For example, for the first time, the user gives a subjective indication to allow it to obtain the Root permission for the request of an external application process, that is, it is added to the authentication list by the main process of the present invention and marked as a state of being allowed to obtain the corresponding permission. You can avoid pop-up window inquiries. The authentication list can also be remotely maintained in combination with the cloud, and the remote communication interface 11 is invoked through the main process to download the latest authentication list data from the cloud regularly or irregularly to update the local authentication list. The advantage of big data makes the data in the certification list more secure.

To adapt to the above situation, the cloud maintains a public authentication list, and the main process of the present invention is installed to upload the data on whether the user is allowed to obtain permission for each program UID, and then perform statistics on each UID according to the statistical method. When most users, for example 60%, allow a certain UID to obtain Root authority, mark the status identifier corresponding to the UID as "Y", otherwise, mark it as "N". The local master process downloads the public authentication list through the remote interface, compares it with the local authentication list, and adds new records in the public authentication list to the local authentication list on the basis of respecting the user's subjective instructions. Of course, for the sake of safety, pop-up queries can be made for records with the same UID but different states in the two tables to see if the user adopts the data of the public authentication list. If the user chooses yes, the UID related to the public authentication list The record replaces the corresponding record in the local authentication list, if not, the subsequent operation is discarded. Obviously, these operations on the local side should be implemented by the authentication list dynamic update module in the maintenance unit, which is more logically divided. The maintenance unit may further include a program upgrade module, which is used to follow up the dynamic update of the program implemented by the present invention. It can be seen that the dynamic maintenance of the authentication list can be realized in this way, so that the authentication list can greatly play its security role from the perspective of technical implementation.

It should be pointed out that the storage form of the authentication list can be a linked list in memory, or a database or a text file stored locally, which can be flexibly implemented by those skilled in the art.

The processing unit 13 is configured to apply for permission to the system for the permission request when the feature is identified as being allowed; and is used to reject the permission request when the feature is not allowed.

Through the processing of the retrieval unit 12, it can be judged whether a permission request is the corresponding feature mark is allowed state, if so, then the main process realized by the present invention can be released for the permission request, and the Root of the permission request system Permission, the system grants Root permission to the corresponding external application process. And if the result obtained by the retrieval unit 12 is that the corresponding feature identification is not allowed, then the main process can reject the permission request, and return a false message to the external application process through its communication interface 11, so that the permission issued by the external application process The request returns without success; alternatively, it can also directly return a reply that the permission request is unsuccessful.

It should be noted that, from the perspective of the life cycle of permissions, the way to obtain root permissions includes permanent root permissions and temporary root permissions. In the case of temporary root authority, the life cycle of the authority function is only a process from booting to shutting down of the operating system, and rooting is still required for the next boot. The realization of the present invention is not limited by this classification, but alternative program realization can be done according to these two different ways. For example, a user interface can be provided for the user to select whether to perform permanent Root or temporary Root, and in combination with the local authentication list, attach the type identification of whether permanent Root or temporary Root to each UID, and then program the requesting user according to different identifications. / process does different permission request opening processing.

As mentioned above, the present invention can implement the execution of subsequent instructions after the permission request through the service process. The service process can be independent, and for the convenience of description, it is called an instruction service process. When the relevant service process of the present invention realizes authority management for the user authority request and successfully obtains the system Root authority, the direct communication between the service process and the user process that initiates the authority request can be bound, and then, the user process sends the service process to the service process. Sending instructions, such as: uninstalling preset applications, installing or uninstalling applications, backing up or restoring application data, enabling or disabling applications, performing memory or cache cleaning functions, etc. The service process is constructed with functions to perform these functions. The service process analyzes the instructions of the user process, calls the function corresponding to the user's target function, and realizes the corresponding function, thereby solving the user's demand.

In summary, it can be seen from the above embodiments that the permission request management function implemented in the present invention has the characteristics of fast and efficient communication, and technical safety and reliability.

The above descriptions are only part of the embodiments of the present invention. It should be pointed out that those skilled in the art can make some improvements and modifications without departing from the principles of the present invention. It should be regarded as the protection scope of the present invention.

Claims (10)

1. A permission request response method, characterized in that, comprising the following steps: Start the communication interface belonging to the system level, and monitor external permission requests through the communication interface; Obtain the requester's feature ID according to the permission request, and check whether the feature ID is allowed in the preset authentication list; When the feature is identified as being allowed, apply for permission to the system for the permission request. 2. The permission request response method according to claim 1, wherein the communication interface at the system level refers to a communication service process based on the Binder mechanism of Android, which is used to communicate with an external application process that initiates a permission request communication. 3. The permission request response method according to claim 1, wherein the characteristic identifier refers to a UID in the Android system, and each UID corresponds to an application. 4. The permission request response method according to claim 1, characterized in that, the preset authentication list stores several feature identifiers, and the existence of the feature identifier in the authentication list indicates that the feature identifier is in an allowed state. 5. The permission request response method according to claim 1, characterized in that, the preset authentication list stores several feature identifiers and a state identification field set corresponding to each feature identifier, when a corresponding feature identifier When the status identification field of is set to an allowed symbol, the symbol is used to indicate that the feature is identified as an allowed status. 6. The permission request response method according to any one of claims 1 to 5, characterized in that it comprises the following steps: obtaining public authentication list data from a remote interface and updating the local authentication list. 7. According to the permission request response method described in any one of claims 1 to 5, it is characterized in that, after adopting the permission request to obtain the Root permission successfully, the communication between the user process and the service process that initiates the permission request is bound, The service process is used to respond to execute instructions requested by the user process. 8. The permission request response method according to any one of claims 1 to 5, characterized in that, in the local authentication list, a permission action period for characterizing the user program corresponding to the feature identifier is set When applying for permission from the system, apply for different types of permissions corresponding to the type identifier. 9. A permission request response device, characterized in that it comprises: The communication interface is activated at the system level and is used to monitor external permission requests; A retrieval unit, configured to obtain the characteristic identifier of the requesting party according to the permission request, and retrieve whether the characteristic identifier is in a permitted state in the preset authentication list; The processing unit is configured to apply for permission to the system for the permission request when the feature identifier is in an allowed state. 10. The permission request response device according to claim 9, wherein the communication interface is a communication service process placed at the system level based on the Binder mechanism of Android, and obtains the communication service process by communicating with an external application process. permission request.