Access control method, related apparatus and system

Abstract

The application provides an access control method, related device and system. In the method, a subject device creates an instance for a caller and a callee respectively, and gives the same UID to the two instances. Then, the subject device can run the instance created by the first part for the callee within the permission range corresponding to the callee. By implementing the method, the caller and the callee share the same UID, without extra consumption of system performance. Through different instances, the subject device can ensure that the instance of the callee runs within the permission range corresponding to the subject device, realize the minimization of the permission of the callee, avoid the problem that the callee steals data outside the permission range during the process that the caller calls the callee, and ensure the data security in the subject device.

Description

[0001] This application claims priority to Chinese Patent Application No. 202110257325.8, filed on March 9, 2021, entitled “Access Control Method, Related Apparatus and System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the fields of computer and communication technology, and in particular to access control methods, related devices and systems. Background Technology

[0003] With the development of smart terminals, the types and numbers of devices in users' lives are increasing, and distributed scenarios where various devices are interconnected are gradually becoming a reality. In distributed scenarios, applications (APPs) on devices calling each other and sharing resources will become a future trend.

[0004] How to avoid data leakage and abuse during the call process, and ensure that devices can securely share resources, so as to provide users with a safe and efficient fully connected scenario, is a new challenge. Summary of the Invention

[0005] This application provides access control methods, related devices and systems that can prevent problems such as the callee stealing data outside its authorized scope during the process of the caller calling the callee, thus ensuring data security in the host device.

[0006] In a first aspect, embodiments of this application provide an access control method applied to a first device. The first device has a caller installed thereon, which is an app or a functional component. An app is a program entity implementing multiple functions, and a functional component is a program entity implementing a single function. The method includes: the first device creating a first instance of the caller and running the first instance within a first permission scope; during the running of the first instance, the first device generating an access request, which is used by the caller to invoke a callee to access a first resource. The callee is an app or a functional component, deployed in the first device and / or a second device, and the first resource includes resources in the first device and / or the second device; the first device creating a second instance of the callee and running the second instance within a second permission scope to access the first resource; the second instance and the first instance have the same user identity UID, but the second permission scope is different from the first permission scope.

[0007] Implementing the method provided in the first aspect, the first instance and the second instance share the same user identity (UID), meaning the first device runs only one application, without consuming additional system performance. Based on this, by creating different instances, the first device can clearly distinguish between the caller and the callee, ensuring that the callee's instance runs within its corresponding permission scope. This minimizes the callee's permissions and prevents issues such as the callee stealing data outside its permission scope during subsequent calls, thus ensuring data security on the first device.

[0008] In conjunction with the first aspect, the first resource can include hardware resources or software resources.

[0009] In conjunction with the first aspect, in some implementations, the callee comprises a first part and a second part, the first part being deployed on a first device and the second part on a second device. The caller and the callee can be developed by different developers. The callee and the caller are simultaneously deployed on the first device, forming a unified application. The first resource includes resources in both the first and second devices.

[0010] For example, the callee can be a FA that provides location functionality. The first part can be used to implement business logic, and the second part can be used to provide a UI. The first resource can include: the location functionality in the first device, and the display screen in the second device.

[0011] In the above implementation, before accessing the first resource, the first device can send an access request to the second device. The first device can create a second instance of the first part of the callee; while the first device is running the second instance within the second permission scope, and while the second device is running the third instance, the first device and the second device communicate to access the first resource; the third instance is an instance of the second part of the callee created by the second device in response to the access request.

[0012] Through the above implementation, the caller and the first part of the callee share the same user identity (UID), meaning the first device only runs one application, without consuming additional system performance. Furthermore, by creating different instances, the first device can clearly distinguish between the caller and the first part of the callee, ensuring that the instance of the first part of the callee runs within its corresponding permission scope. This minimizes the permissions of the first part of the callee, preventing issues such as the first part of the callee stealing data outside its permission scope during subsequent calls to the callee, thus ensuring data security on the first device.

[0013] In conjunction with the above embodiments, the first device and the second device can communicate to access the first resource in the following two ways:

[0014] 1. The first device runs the second instance within the second permission scope, accesses the second resource in the first resource, obtains the first access result, and sends the first access result to the second device so that the second device runs the third instance and accesses the third resource in the first resource according to the first access result.

[0015] For example, the first access result could be the location data obtained by the second instance accessing the location function of the first device during runtime.

[0016] In some embodiments, the first part of the callee is used to implement business logic, and the second part of the callee is used to provide a UI. The second device may run a third instance and display the first user interface based on the first access result to access the third resource. The first user interface may be, for example, a location page, etc.

[0017] 2. The first device receives the second access result, which is obtained by the second device responding to the access request, running the third instance and accessing the third resource in the first resource; the first device runs the second instance within the second permission scope and accesses the second resource in the first resource according to the second access result.

[0018] In conjunction with the above embodiments, in some embodiments, after the first device sends the access request to the second device, it may also send the second part of the callee to the second device.

[0019] In conjunction with the first aspect, in some implementations, the callee is a third-party library deployed in a first device, and the first resource includes resources within the first device. The electronic device can create a second instance of the third-party library and run the second instance within a second set of permissions to access the first resource.

[0020] In the previous implementation, the callee, in the form of a third-party library, is deployed on the same electronic device as the caller, forming a unified application. The caller and the third-party library can be developed by different developers.

[0021] In the previous implementation, the caller and the third-party library share the same user identity (UID), meaning the electronic device only runs one application, without consuming additional system resources. Building on this, by creating different instances, the electronic device can clearly distinguish between the caller and the third-party library, ensuring that each instance of the third-party library runs within its corresponding permission scope. This minimizes the permissions of the third-party library and prevents issues such as the third-party library stealing data outside its authorized scope during subsequent calls, thus ensuring data security within the electronic device.

[0022] In the previous embodiment, the third-party library can be a lib library, an SDK library, or a dynamic link library (.so file), etc.

[0023] In conjunction with the first aspect, in some implementations, the callee comprises a first part and a second part, both deployed on a first device. The caller and the callee can be developed by different developers. The callee and the caller are simultaneously deployed on the first device, forming a unified application. The first resource includes resources within the first device.

[0024] In the above implementation, the first device can create a second instance of the first part of the callee; create a third instance of the second part of the callee; run the second instance within the second permission scope; run the third instance to access the first resource.

[0025] In conjunction with the first aspect and any of the above implementation methods, in some implementations, after the first device creates a first instance of the caller, it can assign a first security domain identity to the first instance. The first access policy corresponding to the first security domain identity indicates that: communication between the first instance and the second instance is not allowed; or, the first instance is not allowed to send data to the second instance; or, the first instance is not allowed to receive data sent by the second instance. The first device can run the first instance within the first permission scope according to the first access policy. This can prevent data obtained by the first instance in the first device according to the first permission scope from being sent to the second device through the second instance, and it can also prevent data obtained by the second device from being sent to the first instance in the first device through the second instance. In other words, this can prevent data leakage between the first device and the second device, ensuring the data security of both devices.

[0026] In conjunction with the first aspect and any of the above implementation methods, in some implementations, after the first device creates a second instance of the callee, it can assign a second security domain identity to the second instance. The second access policy corresponding to the second security domain identity indicates that: the second instance is not allowed to communicate with the first instance, or the second instance is not allowed to send data to the first instance, or the second instance is not allowed to receive data sent by the first instance. The first device can run the second instance within the second permission scope according to the second access policy. This can prevent data obtained by the first instance in the first device according to the first permission scope from being sent to the second device through the second instance, and it can also prevent data obtained by the second device from being sent to the first instance in the first device through the second instance. In other words, this can prevent data leakage between the first device and the second device, ensuring the data security of both devices.

[0027] In conjunction with the first aspect and any of the above-described implementation methods, in some implementations, the first device can assign a first UID and a first process identifier (PID) to the first instance; and assign a first UID and a second PID to the second instance. This allows the first instance and the second instance to share the same UID, i.e., run as the same application. Furthermore, the first device can distinguish between the first instance and the second instance using the PID, thereby enabling access control for each instance.

[0028] In conjunction with the first aspect and any of the above embodiments, in some embodiments, the first device may create a first instance in response to a detected first operation for initiating a caller.

[0029] In conjunction with the first aspect and any of the above embodiments, in some embodiments, the first device may display a second user interface and, in response to a second operation received on the second user interface, send an access request to the second device.

[0030] In conjunction with the first aspect and any of the above-described embodiments, in some embodiments, the second scope of authority and the first scope of authority may be partially the same or completely different. In some embodiments, the second scope of authority may be a portion of the first scope of authority.

[0031] The first permission scope can be granted to the caller by the first device by default, or it can be granted to the caller by the user.

[0032] The second permission scope can be granted to the callee by default from the caller in the first device, or it can be granted to the callee by the user. For example, the first device can display a third user interface, receive a third operation on the third user interface, and determine the second permission scope based on the third operation.

[0033] Secondly, this application provides an access control method applied to a communication system including a first device and a second device. The method includes: the first device creating a first instance of a caller and running the first instance within a first permission scope; during the running of the first instance, the first device sending an access request to the second device, the access request carrying: an identifier of the callee and an identifier of a first resource; the caller is an APP or a functional component, where an APP is a program entity implementing multiple functions, and a functional component is a program entity implementing a single function; the first device creating a second instance of a first part of the callee; the second device, in response to the access request, creating a third instance of the second part of the callee; during the running of the second instance within a second permission scope and during the running of the third instance by the second device, the first device and the second device communicating to access the first resource; wherein the second instance and the first instance have the same user identity UID, and the second permission scope is different from the first permission scope.

[0034] In the method provided in the second aspect, the callee is deployed separately on the first and second devices. The caller and callee can be developed by different developers. The callee and caller are deployed simultaneously on the first device, forming a unified application.

[0035] Implementing the method provided in the second aspect, the caller and the first part of the callee share the same user identity (UID), meaning the first device only runs one application, without consuming additional system performance. Based on this, by creating different instances, the first device can clearly distinguish between the caller and the first part of the callee, ensuring that the instance of the first part of the callee runs within its corresponding permission scope. This minimizes the permissions of the first part of the callee, preventing issues such as the first part of the callee stealing data outside its permission scope during subsequent calls to the callee, thus ensuring data security on the first device.

[0036] In conjunction with the second aspect, the first resource may include hardware resources or software resources. The first resource may include a second resource located in the first device and a third resource located in the second device. For example, when the callee is a FA providing positioning functionality, the first resource may include: the positioning function in the first device and the display screen in the second device.

[0037] In conjunction with the second aspect, the methods by which the first device and the second device communicate to access the first resource may include the following two:

[0038] 1. The first device runs the second instance within the second permission scope, accesses the second resource in the first resource, obtains the first access result, and sends the first access result to the second device; the second device runs the third instance and accesses the third resource in the first resource according to the first access result.

[0039] For example, the first access result could be the location data obtained by the second instance accessing the location function of the first device during runtime.

[0040] In some embodiments, the first part of the callee is used to implement business logic, and the second part of the callee is used to provide a UI. The second device may run a third instance and display the first user interface based on the first access result to access the third resource. The first user interface may be, for example, a location page, etc.

[0041] 2. In response to the access request, the second device runs the third instance, accesses the third resource in the first resource, obtains the second access result, and sends the second access result to the first device; the first device runs the second instance within the second permission scope and accesses the second resource in the first resource according to the second access result.

[0042] In conjunction with the second aspect, in some implementations, before the second device creates a third instance of the second part of the callee in response to an access request, the first device may send the second part of the callee to the second device; or, the second device may download the second part of the callee from the network in response to an access request.

[0043] In conjunction with the second aspect, in some other embodiments, the second device may pre-configure a second part of the callee.

[0044] In conjunction with the second aspect, in some implementations, after the first device creates the first instance, it can assign a first security domain identity to the first instance. The first access policy corresponding to the first security domain identity indicates that communication between the first instance and the second instance is not allowed, or that the first instance is not allowed to send data to the second instance, or that the first instance is not allowed to receive data sent by the second instance. Furthermore, the first device runs the first instance within the first permission scope, according to the first access policy. This prevents data obtained by the first instance within the first device according to the first permission scope from being sent to the second device through the second instance, and also prevents data obtained by the second device from being sent to the first instance within the first device through the second instance. In other words, this prevents data leakage between the first device and the second device, ensuring the data security of both devices.

[0045] In conjunction with the second aspect, in some implementations, after the first device creates the second instance, it can assign a second security domain identity to the second instance. The second access policy corresponding to the second security domain identity indicates that the second instance is not allowed to communicate with the first instance, or the second instance is not allowed to send data to the first instance, or the second instance is not allowed to receive data sent by the first instance. Furthermore, the first device runs the second instance within the second permission scope, according to the second access policy. This prevents data obtained by the first instance in the first device according to the first permission scope from being sent to the second device through the second instance, and also prevents data obtained by the second device from being sent to the first instance in the first device through the second instance. In other words, this prevents data leakage between the first device and the second device, ensuring the data security of both devices.

[0046] In conjunction with the second aspect, in some implementations, the first device can assign a first UID and a first process identifier (PID) to the first instance; and assign a first UID and a second PID to the second instance. This allows the first and second instances to share the same UID, meaning they run as the same application. Furthermore, the first device can distinguish between the first and second instances using the PID, thereby enabling access control for each instance.

[0047] In conjunction with the second aspect, in some implementations, the first device may create a first instance in response to a detected first operation for initiating a caller.

[0048] In conjunction with the second aspect, in some embodiments, the first device may display a second user interface and, in response to a second operation received on the second user interface, send an access request to the second device.

[0049] In conjunction with the second aspect, in some implementations, the second scope of authority and the first scope of authority may be partially the same or completely different. In some implementations, the second scope of authority may be a portion of the first scope of authority.

[0050] The first permission scope can be granted to the caller by the first device by default, or it can be granted to the caller by the user.

[0051] The second permission scope can be granted to the callee by default from the caller in the first device, or it can be granted to the callee by the user. For example, the first device can display a third user interface, receive a third operation on the third user interface, and determine the second permission scope based on the third operation.

[0052] Thirdly, embodiments of this application provide an electronic device, including: a memory and one or more processors; the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and one or more processors call the computer instructions to cause the electronic device to perform the method as described in the first aspect or any embodiment of the first aspect.

[0053] Fourthly, embodiments of this application provide a communication system, including a first device and a second device, wherein the first device is used to perform the method as described in the first aspect or any embodiment of the first aspect.

[0054] Fifthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in the first aspect or any embodiment of the first aspect.

[0055] Sixthly, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform a method as described in the first aspect or any of the embodiments of the first aspect.

[0056] By implementing the technical solution provided in this application, an electronic device can create different instances for the caller and the callee, but they share a single UID. In this way, the electronic device runs only one application, without consuming additional system performance. Furthermore, by creating different instances, the electronic device can clearly distinguish between the caller and the callee, ensuring that the callee's instance runs within its corresponding permission scope. This minimizes the callee's permissions and prevents issues such as the callee stealing data outside its permission scope during subsequent calls, thus ensuring data security within the electronic device. Attached Figure Description

[0057] Figure 1 A schematic diagram of the communication system 10 provided in this application embodiment;

[0058] Figure 2A This application provides a distributed scenario for an embodiment of the present application;

[0059] Figure 2B This is a form of service provided by third-party libraries to callers;

[0060] Figure 3 Several ways to prevent the callee from having excessive privileges;

[0061] Figure 4A A flowchart of the access control method provided in the embodiments of this application;

[0062] Figure 4B The operating model of the application provided in the embodiments of this application;

[0063] Figures 5A-5D A set of user interfaces implemented on a host device for embodiments of this application;

[0064] Figures 5E-5F A set of user interfaces implemented on an object device as provided in the embodiments of this application;

[0065] Figure 6A A hardware structure diagram of the electronic device provided in the embodiments of this application;

[0066] Figure 6B A software structure diagram of the electronic device provided in the embodiments of this application;

[0067] Figure 6C A software structure diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0068] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0069] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0070] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0071] First, the communication system provided in the embodiments of this application will be introduced.

[0072] like Figure 1 As shown, this application embodiment provides a communication system 10. The communication system 10 includes multiple electronic devices. The communication system 10 can also be referred to as a distributed system 10.

[0073] The distributed system 10 includes multiple electronic devices, all of which are smart terminal devices and can be of various types. This application embodiment does not limit the specific types of these multiple electronic devices. For example, these multiple electronic devices may include mobile phones, but may also include tablets, desktop computers, laptops, handheld computers, smart screens, wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, in-vehicle systems, smart headphones, game consoles, and may also include Internet of Things (IoT) devices or smart home devices such as smart water heaters, smart lights, smart air conditioners, etc. However, the multiple devices in the distributed system 10 may also include non-portable terminal devices such as laptops with touch-sensitive surfaces or touch panels, and desktop computers with touch-sensitive surfaces or touch panels.

[0074] When multiple electronic devices in the distributed system 10 are devices deployed in a home, the distributed system 10 can also be referred to as a home distributed system.

[0075] In distributed system 10, multiple electronic devices can connect by logging into the same account. For example, multiple electronic devices can log into the same Huawei account and remotely connect and communicate through a server.

[0076] Multiple electronic devices in the distributed system 10 can also log in to different accounts, but are connected through a binding method. For example, after electronic device 100 logs in to its account, it can bind electronic devices 200 that are logged in to different accounts or not logged in, in a device management application. Electronic devices 100 and 200 can then communicate through this application. In the following embodiments of this application, electronic device 100 can be any electronic device in the distributed system 10, and electronic device 200 can also be any electronic device in the distributed system 10. For example, electronic device 100 is a smartwatch, and electronic device 200 is a smart screen.

[0077] Multiple electronic devices in the distributed system 10 can also establish connections by scanning QR codes, NFC tap-to-connect, etc., without any restrictions.

[0078] The communication connections established between multiple electronic devices in the distributed system 10 may include, but are not limited to: wired connections, wireless connections such as Bluetooth (BT) connections, wireless local area networks (WLANs) such as wireless fidelity point-to-point (Wi-Fi P2P) connections, near field communication (NFC) connections, infrared (IR) connections, and remote connections, etc.

[0079] Furthermore, multiple electronic devices in a distributed system can also be connected and communicate using any of the above methods, and this application embodiment does not impose any restrictions on this.

[0080] These multiple electronic devices can be configured with different software operating systems (OS), including but not limited to... And so on. Among them, It refers to Huawei's HarmonyOS operating system.

[0081] These multiple electronic devices can also all be configured with the same software operating system; for example, they can all be configured with... The software systems of multiple electronic devices are At that time, distributed system 10 can be regarded as a super terminal.

[0082] In this embodiment, each device in the distributed system 10 can install traditional applications (APPs), such as camera applications, gallery applications, settings applications, etc. In subsequent embodiments, traditional APPs can be simply referred to as APPs.

[0083] Furthermore, the distributed system 10 provided in this application embodiment can install distributed applications. These distributed applications can be system applications or third-party applications; no limitation is made here.

[0084] Unlike apps that include multiple capabilities, distributed applications can be deployed on a single capability basis. A distributed application consists of one or more functional components.

[0085] A functional component is the smallest independently operable unit in an electronic device; it's a concept that abstracts and encapsulates a single capability. While an app combines multiple functions, a functional component treats each function as a separate, service-oriented capability, existing independently. In other words, a functional component is a program entity that implements a single function.

[0086] Each functional component can be downloaded, installed, and run independently. Multiple functional components that make up the same distributed application can be deployed on the same electronic device in the distributed system 10, or on different electronic devices.

[0087] "Functional component" is simply a term used in this embodiment, and its meaning has been described in this embodiment. Its name does not constitute any limitation on this embodiment. Furthermore, in other embodiments of this application, functional component may also be referred to as system component, system service, business function, or other terms. Subsequent embodiments of this application will uniformly use the term "functional component" for description.

[0088] by For example, The functional components can include the following two categories:

[0089] (1) Feature ability, FA.

[0090] A Functional Interface (FA) is a set of one or more UI components that provide the ability to interact with the user. For example, the navigation interface in a map application or the video call interface in an instant messaging application can be implemented as an FA.

[0091] In some embodiments, the FA is developed based on the MVVM (model-view-view-model) pattern, separating the UI and business logic. That is, the business logic part and the UI part of the FA are deployed separately. For example, the UI part of the FA can be deployed on one electronic device, while the business logic part of the FA can be integrated into other apps and installed on another electronic device.

[0092] The UI portion of a FA (Feature Analyzer) is used to provide or display a user interface. The UI portion of a FA can be implemented as code or a functional module; there are no restrictions on this.

[0093] The business logic section of the FA (Software Provider) is used to provide the data required to display the aforementioned UI. This business logic section can be implemented as code or a functional module; there are no restrictions here.

[0094] In practice, the device where the UI part of the FA is located can communicate with the device where the business logic part of the FA is located and obtain the data required to display the UI, and then display the UI based on the data.

[0095] FA supports page template capabilities, such as Empty Ability, Login Ability, and Setting Ability. FA uses a scripting language (JavaScript, JS) to provide a declarative development model, employing HTML-like and cascading style sheet (CSS) declarative programming languages ​​for page layout and styling, and also supports ECMAScript-compliant JS for providing page business logic.

[0096] FA features include installation-free operation, standalone operation, cross-device UI migration, and cross-device binary migration capabilities. FA also boasts multi-platform deployment and distributed execution.

[0097] FA can call AA or APP to achieve more and more complex functions.

[0098] (2) Particle ability, PA.

[0099] PA (Application Component) is a UI-less functional component that provides support for FA (Application Function). For example, PA can provide computing power as a background service or provide data access capabilities as a data warehouse. Features such as beautification, location services, and audio / video encoding / decoding can be encapsulated as PAs.

[0100] PA also features multi-terminal deployment and distributed execution. PA only depends on system services and has no dependencies on other PAs.

[0101] PA essentially encapsulates remote virtualization, remote invocation, PA management, cross-platform compatibility, and security, providing developers with cross-device service enablement and invocation capabilities. This allows other devices to access the computing power of PA and collaborate with other devices to complete computational tasks. PA supports Service Ability and Data Ability. Service Ability provides the ability to run background tasks, while Data Ability provides a unified data access abstraction to the outside world.

[0102] PA can call FA or APP to achieve more and more complex functions.

[0103] It is understood that "FA" and "PA" are just one term used in this embodiment, and may be referred to as other terms in other embodiments of this application. For example, "PA" and "FA" may also be referred to as atomic capability (AA), atomic application, meta-capability, atomic service, feature capability, and other terms.

[0104] The multiple functional components that make up a distributed application can be developed or provided by the same developer, or they can be developed or provided separately by multiple developers; there are no restrictions here. Collaborating on functional components by different developers can improve the development efficiency of distributed applications.

[0105] In this embodiment, the functional component provides a standardized interface for invocation. The app can invoke the functional component. In some cases, the functional component can also invoke other functional components or the app. Furthermore, the invoked functional component can continue to invoke other functional components or the app; this multi-level invocation method can be called chained invocation.

[0106] After establishing communication connections among the devices in distributed system 10, each device will synchronize the functional component information and APP information of other devices in the distributed system. Specifically, each device can synchronize the names of its installed functional components and APPs with other devices, so that they can subsequently call the FA, PA, and other functional components of other devices in distributed system 10. Which callers can access the FA, PA, and other functional components, and which other functional components can be accessed, can be pre-set and recorded in each electronic device. In some other embodiments, each device can also synchronize its device identifier, device type, etc., with other devices in the distributed system.

[0107] In subsequent embodiments of this application: the party initiating the call to a functional component or APP can be referred to as the caller. The caller can be, for example, an APP, a service, a FA, or a PA. The initial initiator of the entire call chain can be referred to as the first caller. The first caller can be, for example, an APP or a FA. For example, if the call chain is: APP1 calls PA1, PA1 calls PA2, PA2 calls FA1, then APP1 is the first caller. As another example, if the call chain is: FA1 calls PA1, PA1 calls PA2, then FA1 is the first caller.

[0108] In the entire call chain, the party called in the middle and the party called last can both be called the callee. The callee can be, for example, an APP, a FA, or a PA.

[0109] In some embodiments of this application, the caller may also be referred to as the subject application, and the callee may also be referred to as the object application.

[0110] In a call chain, the caller and the callee can be deployed on the same electronic device or on different electronic devices.

[0111] The device where the caller is located is called the subject device, and the device where the callee is located is called the object device. Figure 1The roles of the principal and object devices in the distributed system shown can be referred to the relevant descriptions in the subsequent method embodiments, and will not be repeated here.

[0112] The applications referred to in the following embodiments of this application may include APPs or functional components. Applications can be distinguished by different application identifiers (APP IDs).

[0113] refer to Figure 2A , Figure 2A An example of a possible distributed business scenario provided by an embodiment of this application is illustrated.

[0114] like Figure 2A As shown, the distributed system includes smartwatches and smartphones. The smartwatches and smartphones are interconnected. Smartwatches and smartphones can be configured with different software operating systems (OS), for example, smartwatches can be configured with different operating systems (OS). The system and smartphones can be configured system.

[0115] Among these, smartphones can have food delivery apps installed. These apps are applications installed on electronic devices to provide food delivery services to users. The food delivery app on the smartphone can integrate the business logic of the location-based service provider (FA), while the UI of this FA is deployed on a smartwatch. The UI of the location-based FA can be pre-installed on the smartwatch, migrated from the smartphone to the smartwatch, or downloaded by the smartwatch from the network.

[0116] Food delivery apps on smartphones can act as callers, invoking the location-based service provider (FA) to access its location capabilities. Specifically, the smartphone can run the business logic of the FA integrated within the food delivery app to obtain the data required for the location page and send that data to a smartwatch. The smartwatch can then run the UI of the FA and use this data to provide a location page for viewing the delivery person's location.

[0117] It can be seen that, through Figure 1 The distributed system 10 shown, and, Figure 2A The distributed scenario shown can integrate the software and hardware capabilities of different devices to achieve a smart, full-scenario experience.

[0118] When a caller integrates the business logic of the FA (User Advisor), this business logic runs with the same user identity or user identifier (user ID, UID) as the caller, which can lead to potential privilege escalation and data leakage risks. For example, the business logic of the FA could leverage the caller's privileges to access sensitive resources on the main device and potentially pass these resources to the device where the UI of the FA resides, resulting in data leakage. Sensitive resources refer to high-security resources on a device whose leakage would pose a significant risk to the user. As another example, if the UI of the FA sends important business data to the business logic, this data could be maliciously obtained by the caller, leading to data leakage.

[0119] Apart from Figure 2A The example shown illustrates the potential for data leakage when a caller invokes FA. Similar data leakage issues may also occur when other callers integrate third-party code.

[0120] refer to Figure 2B , Figure 2B This example illustrates a scenario where the callee provides services to the caller in the form of a third-party library.

[0121] like Figure 2B As shown, a caller (such as an app) in an electronic device can integrate third-party libraries. When the caller runs, it can invoke these libraries to obtain the various services they provide. Because the third-party library and the caller's own code run under the same user identity, the third-party library can exploit the caller's permissions to access sensitive resources of the electronic device and may pass these sensitive resources to other devices or other applications within the electronic device, leading to data leakage.

[0122] Here, the developers of third-party libraries are different from the developers of the callers. Third-party libraries may include, for example, software development kits (SDKs) or dynamic link libraries (.so files), etc., without any restrictions.

[0123] In order to avoid Figure 2A or Figure 2B Data leakage issues can be addressed by using a monitor to monitor the permissions of the business logic section / third-party libraries in the financial software.

[0124] refer to Figure 3 In (1), the monitor can be set at the application layer, for example, it can be integrated into the caller.

[0125] refer to Figure 3 In (2), the monitor can also be set in the frame layer.

[0126] The monitor can monitor the operations that the business logic part / third-party library of the FA can perform during operation based on the actual permissions of the FA / third-party library in the electronic device, and try to ensure that the business logic part / third-party library of the FA runs within its own permission scope.

[0127] However, even with the introduction of a monitor, the business logic part of the FA / third-party library still runs with the same user identity (UID) as the caller's own code. The monitor cannot easily distinguish between the caller's own code and the business logic part of the FA / third-party library. Therefore, the supervisory role of the monitor is limited and it still cannot guarantee that there is no risk of data leakage during the call process.

[0128] To avoid data leakage during the process of a caller calling a callee, the following embodiments of this application provide an access control method.

[0129] In this access control method, the caller, which is an app or functional component, is installed on the principal device. When the caller invokes the callee, the principal device can create an instance for both the caller and the callee, assigning both instances the same user identity (UID). Subsequently, the principal device can run the instance created for the callee within the corresponding permissions of the callee.

[0130] In some embodiments, the callee may comprise a first part and a second part, which may be deployed on the same device or different devices. In other embodiments, the callee may be implemented as a third-party library, and the third-party library and the caller may be deployed on the same host device.

[0131] On one hand, this method can be applied to a distributed system comprising multiple electronic devices. This distributed system includes a subject device and an object device. The subject device has a caller and a first part of the callee installed. Furthermore, the caller and the first part of the callee in the subject device are integrated into a single application. The other part of the callee, i.e., the second part of the callee, can be installed in the object device.

[0132] in:

[0133] The caller can be an app or a functional component. The caller specifically provides the various functions implemented by the caller itself. For example, the caller in the main device is... Figure 2A In the example of a food delivery app, this caller provides food delivery services, such as allowing users to browse food delivery merchants, submit orders, and rate orders. This caller can be implemented as its own code or functional module.

[0134] The callee can also be an app or a functional component.

[0135] The first part of the callee provides one portion of the callee's functionality. The second part of the callee provides the remaining portion of the callee's functionality. Together, the first and second parts of the callee complete all the functionality provided by the callee.

[0136] For example, the callee is Figure 2A When the FA provides location functionality in the example, the first part can be the business logic part used to obtain the data required to display the UI, mainly responsible for internal processing operations such as calculation and detection, and the second part can be the UI part used to provide or display the UI.

[0137] In summary, after the main device integrates the first part of the caller and the callee, the actual functions it provides include: the functions provided by the caller, and the functions provided by the first part of the callee.

[0138] The caller and the callee can be developed by different developers.

[0139] The first part of the application integrates the caller and the callee, forming a whole in the outside world. Users do not distinguish or perceive that the whole application actually contains two parts.

[0140] For example, when a user downloads the complete application from an app store through the main device, the electronic device directly downloads the first part of the caller and callee. The user is only aware that the main device has downloaded a complete application, and is not aware that the main device has downloaded the first part of the caller and callee.

[0141] For example, the host device can store the first part of the caller and the callee in the overall application in the same storage area.

[0142] For example, after a user triggers the main device to run the overall application, the main device will provide a series of user interfaces for the caller. The user can use the functions provided by the first part of the caller and the callee through these user interfaces. During this process, since the user is always operating within the same user interface provided by the overall application, they will not perceive the difference between the first part of the caller and the callee, and will consider the functions of the first part of the caller and the callee to be functions provided by the overall application.

[0143] In the access control method provided in this application embodiment, the principal device creates an instance for both the caller and the first part of the callee, and assigns the same user identity (UID) to both instances. Then, the principal device can run the instance created for the first part of the callee within the permission scope corresponding to that first part.

[0144] The UID is used to identify the user to whom the app or functional component belongs. Typically, electronic devices assign different UIDs to different installed apps or functional components for differentiation. Electronic devices can use UIDs to identify different apps or functional components and manage their permissions.

[0145] In this embodiment, the caller and the first part of the callee share the same user identity (UID), meaning the main device runs only one application, without consuming additional system performance. Based on this, by creating different instances, the main device can clearly distinguish between the caller and the first part of the callee, ensuring that the instance of the first part of the callee runs within its corresponding permission scope. This minimizes the permissions of the first part of the callee, preventing issues such as the first part of the callee stealing data outside its permission scope during subsequent calls to the callee, thus ensuring data security on the main device.

[0146] An instance is a running application or functional component. In the embodiments of this application, an instance can refer to a process or a thread. A process is an execution activity of an application on a computer. A thread is a single sequential control flow in the execution of an application. A process can include multiple threads. Instances can be distinguished by a process identifier (PID). Each time an electronic device creates an instance, it assigns that instance a unique PID.

[0147] In some embodiments, the principal device may also assign different security domain identities to the caller instance and the first part of the callee instance, and run the caller instance and the first part of the callee instance according to the access policy corresponding to their respective security domain identities. If the access policy indicates that the caller instance and the first part of the callee instance cannot communicate with each other, it can be guaranteed that the data that the caller instance can obtain and the data that the first part of the callee instance can obtain will not be leaked to each other, thus ensuring data security in both the principal device and the object device. For details regarding the access policy, please refer to the relevant description in the subsequent method embodiments.

[0148] The following section details access control methods applied in distributed systems.

[0149] refer to Figure 4A , Figure 4A This is a flowchart illustrating the access control method provided in an embodiment of this application. Figure 4A As shown, the method may include the following steps:

[0150] S101, the main device detects the user operation of the initiator.

[0151] In this embodiment of the application, the main device is pre-configured with a caller.

[0152] exist Figure 4A For the definitions and descriptions of the caller, the first part of the callee, and the second part of the callee in the method shown, please refer to the relevant descriptions above.

[0153] This application does not limit the user operation that initiates the caller's actions. For example, it can be a touch operation detected by the main device acting on the display screen, a voice command, a shaking operation, etc. The user operation that initiates the caller's actions can be referred to as the first operation.

[0154] For example, refer to Figure 2A In the distributed business scenario shown, when a smartphone acts as the primary device and a food delivery app acts as the caller, the primary device can display something like this: Figure 5A The user interface 51 shown.

[0155] Figure 5A An exemplary user interface 51 for displaying installed applications is shown on the main device. This user interface 51 displays: a status bar, a calendar indicator, a weather indicator, a tray with icons of commonly used applications, other application icons such as an icon 501 for a food delivery app, a gallery icon, a file browser icon, etc. The status bar may include: one or more signal strength indicators for mobile communication signals (also known as cellular signals), a Bluetooth indicator, one or more signal strength indicators for Wi-Fi signals, a battery status indicator, a time indicator, etc. It is not limited to these. Figure 5A The user interface shown may also include a navigation bar, sidebar, etc. In some embodiments, Figure 5A The user interface 51 shown in the example can be referred to as the home screen.

[0156] like Figure 5A As shown, the user operation detected by the main device that initiates the caller can be a user operation (such as a click operation, a touch operation, etc.) that is applied to the icon 501 of the food delivery app.

[0157] S102, in response to the user operation that initiates the caller, the main device creates an instance of the caller.

[0158] For the definition and description of the instance, please refer to the relevant description above.

[0159] Specifically, the primary device can respond to the user's action that initiates the caller by running the caller's code, that is, creating an instance of the caller. For simplicity, the instance of the caller created by the primary device will be referred to as the first instance.

[0160] When the primary device creates the first instance, it can assign a first UID to that instance. Specifically, the primary device can select a UID from its own preset data range and assign it to the first instance. The primary device will assign other UIDs to other apps or functional components running on it. Therefore, the first UID can be used to distinguish the first instance from other apps or functional components that are different from the caller.

[0161] When the host device creates the first instance, it can assign a first PID to that first instance. The first PID can be used to distinguish that first instance from other instances in the host device.

[0162] S103, the main device runs the first instance within the first permission scope.

[0163] After the first instance is created, the main device can run the first instance within the first permission scope to provide various functions within that first permission scope. For example, the food delivery service provided by a food delivery app can provide users with the ability to browse food delivery merchants, submit food delivery orders, and rate food delivery orders.

[0164] The first scope of permissions can be granted to the caller by default by the main device or by the user. For example, the main device may grant the caller permissions to access the display screen and audio devices by default. Alternatively, the user may grant the caller permissions to use the main device's gallery, network connectivity, location services, notification functions, and to access recipient information stored on the main device. This application does not limit the method by which the user grants the caller the first scope of permissions. For example, the user can grant permissions in the user interface provided by the main device's settings application, or in the user interface provided by this first instance (e.g., a pop-up window); there are no restrictions here.

[0165] In some embodiments, the host device may run the first instance to display the corresponding user interface. For example, refer to... Figure 5B , Figure 5B The user interface 52 provided by the first instance in the main device is shown. This user interface 52 may be an interface that allows users to browse food delivery merchants.

[0166] S104, during the operation of the first instance, the main device generates an access request and sends the access request to the object device. The access request carries the identifier of the caller, the identifier of the callee, and the identifier of the first resource. The access request is used by the caller to call the callee to access the first resource.

[0167] In some embodiments, the host device may generate the access request in response to a received user operation. The user operation used to trigger the host device to generate the access request may be referred to as the second operation.

[0168] For example, refer to Figure 5C , Figure 5C The image shows a user interface 53 displayed on the main device after a user initiates a food delivery order. This user interface 53 can display: the merchant's name, the name and image of the purchased goods, the order's delivery status, delivery information (such as delivery time, address, recipient, etc.), a control 502 for viewing the delivery person's location, and so on.

[0169] like Figure 5C As shown, the main device can receive user operations (such as click operations, touch operations, etc.) applied to control 502, and generate a corresponding access request in response to the user operation. This access request carries the identifier of the caller (i.e., the identifier of a food delivery app), the identifier of the callee (the identifier of the FA providing location functionality), and the identifier of the first resource (i.e., the identifier of location capabilities). Figure 5C In the example, user interface 53 can be called the second user interface, and the operation performed on control 502 is the second operation.

[0170] In other embodiments, the primary device may also autonomously initiate the access request to the secondary device under certain circumstances. For example, after a user initiates a food delivery order through the primary device, the primary device can autonomously generate an access request for the food delivery app to call the location-based service provider (FA), without requiring user intervention.

[0171] In this embodiment of the application, the identifier of the caller and the identifier of the callee can be the application identifier (APP ID).

[0172] In this embodiment, the first resource can be a software resource or a hardware resource. Hardware resources may include, for example, the device's camera, fingerprint sensor, audio device, display screen, motor, flash, etc. Software resources may include, for example, the device's memory resources, computing power (e.g., beautification algorithm capabilities, audio / video encoding / decoding capabilities), network capabilities, positioning functions, etc.

[0173] In this embodiment, the first resource may include two parts: a second resource located in the subject device, and a third resource located in the object device. This embodiment does not limit the specific content of the second and third resources. For example, when the callee is... Figure 2A When the FA provides positioning functionality in the example, the first resource includes: positioning functionality in the subject device, and a display screen and associated display functionality in the object device.

[0174] The specifics of the caller, the callee, and the primary resource depend on the user's actions or the operation of the main device, and are not limited here.

[0175] S105, after the main device generates an access request, it creates an instance of the first part of the callee.

[0176] In some embodiments, the host device has a pre-configured first part of the callee, so an instance of the first part of the callee can be created directly after an access request is generated.

[0177] In other embodiments, the subject device does not pre-configure the first part of the callee. In this case, the object device may send the first part of the callee to the subject device after receiving the access request sent by the subject device in S104.

[0178] In other implementations, after the host device generates an access request in S104, it can directly download and obtain the first part of the callee from the network.

[0179] After the host device obtains the first part of the callee, it can integrate the first part of the callee and the caller itself into a whole application and run the first part of the callee, that is, create an instance of the first part of the callee.

[0180] For simplicity, the instance of the first part of the callee in the main device will be referred to as the second instance.

[0181] When the primary device creates the second instance, it assigns the same first UID as the first instance. In other words, although the primary device simultaneously runs the first part of both the caller and the callee within the caller, since the first and second instances within the caller share the same user identity (UID), the primary device is essentially running a single application, without consuming additional system performance and resources.

[0182] When the primary device creates a second instance, it can assign a second PID to that second instance, which is different from the first PID. The second PID can be used to distinguish the second instance from other instances in the primary device (such as the first instance).

[0183] Optional step S106: The main device assigns a first security domain identity to the first instance and assigns a second security domain identity to the second instance.

[0184] The main device can assign a first security domain identity to the first instance after it is created, and assign a second security domain identity to the second instance after it is created.

[0185] Specifically, the host device can allocate or create multiple security domains at the kernel layer, with each security domain corresponding to a security domain identity (i.e., identifier). For example, the first security domain corresponds to the first security domain identity, and the second security domain corresponds to the second security domain identity.

[0186] A security domain, residing at the kernel layer, is a collection of logical regions operating within the same environment, sharing similar security requirements and policies, and exhibiting mutual trust, association, or interaction. A security domain can be viewed as a kernel-level sandbox, providing kernel-level security isolation. No user or application can modify the access policy of a security domain. Access control between security domains is implemented based on mandatory access control (MAC) policies. MAC policies define which subjects can access which objects, and these policies can only be enforced by the device system; no user or application can modify them. Therefore, different security domains can achieve kernel-level isolation, providing system-level security.

[0187] Each security domain defines a corresponding access policy, specifying which users can perform which types of operations on which data or processes. For example, an electronic device assigns a security domain identity to each newly created process. When a process accesses a specific file or directory, or engages in inter-process communication with other processes, the access policy corresponding to that security domain identity, as defined in the security policy file, determines whether the instance is allowed to perform these operations. Different security identities can have different access policies.

[0188] Simply put, an instance's security policy defines the rules for communication between that instance and other processes.

[0189] This application embodiment does not limit the specific content of the first security policy corresponding to the first security domain identity and the second security policy corresponding to the second security domain identity.

[0190] Taking the second security policy corresponding to the second security domain identity as an example, the following is a brief introduction to several possible implementation forms of this second security policy:

[0191] (1) The second security policy may include: allowing communication between a second instance and a third instance that belong to the same callee.

[0192] (2) The second security policy may include: disallowing the second instance from communicating with other instances in the main device, that is, disallowing the second instance from communicating with the first instance.

[0193] (3) The second security policy may include: disallowing the second instance from receiving sensitive data from other instances (e.g., the second instance) that belong to the same UID.

[0194] (4) The second security policy may include: allowing the second instance to receive data sent by other instances in the main device, but not allowing the second instance to send the data it has obtained to other instances in the main device (e.g., the first instance). That is, only one-way communication between the second instance and other instances is allowed.

[0195] The first security policy corresponding to the first security domain identity is similar to that described above, and is briefly listed below:

[0196] (1) The first security policy may include: disallowing the first instance from communicating with other instances in the main device, that is, disallowing the first instance from communicating with the second instance.

[0197] (2) The first security policy may include: disallowing the first instance from receiving sensitive data from other instances (e.g., the second instance) that belong to the same UID.

[0198] (3) The first security policy may include: allowing the first instance to receive data sent by other instances in the main device, but not allowing the first instance to send the data it has obtained to other instances in the main device (e.g., the second instance). That is, only one-way communication between the first instance and other instances is allowed.

[0199] The specific content of the security strategy described above is for illustrative purposes only. In actual implementation, this content can be customized according to the actual situation, and no restrictions are imposed here.

[0200] In some embodiments, the electronic device 100 may assign different security domain identifiers to the first instance and the second instance only when it is confirmed that the developers of the caller and the callee are different; otherwise, it may assign the same security domain identifier to them. This ensures that data between callers and callees with different developers is not leaked, and reduces the resources consumed in assigning security domain identifiers when the developers are the same.

[0201] S107, In response to the received access request, the object device creates an instance of the second part of the callee.

[0202] For the sake of simplicity, the second instance of the callee in the object device will be referred to as the third instance.

[0203] In some embodiments, the object device is pre-configured with a second part of the callee.

[0204] In other embodiments, the object device does not pre-configure the second part of the callee. In this case, the object device can obtain the second part of the callee directly from the network after receiving the second part of the callee from the subject device, or after receiving an access request from the subject device.

[0205] In some embodiments, after receiving an access request from the subject device, the object device can directly respond to the access request and create an instance of the second part of the callee.

[0206] In other embodiments, after receiving an access request from the subject device, the object device may output a prompt message to encourage the user to respond to the access request. Only after the user agrees to respond to the access request will the object device respond to the access request and create an instance of the second part of the callee. For example, refer to... Figure 5E , Figure 5E An exemplary user interface 55 is shown, which appears when the object device receives an access request. The user interface 55 displays: a prompt message 506, a control 507, and a control 508. The prompt message 506 prompts the user whether to respond to the access request initiated by the subject device. The control 507 can listen for user actions; the subject device can respond to these actions by granting an access request. The control 508 can listen for user actions; the subject device can refuse to grant an access request by granting these actions.

[0207] The order of S105-S106 and S107 is not limited in this embodiment.

[0208] S108, the principal device runs a second instance within the second permission scope, the object device runs a third instance, and the principal device and the object device communicate to access the first resource.

[0209] The second scope of permissions differs from the first scope of permissions. In some embodiments, the second scope of permissions and the first scope of permissions may be partially the same or completely different. In some embodiments, the second scope of permissions may be a portion of the first scope of permissions.

[0210] The second permission scope is the permission scope of the callee.

[0211] In some embodiments, the second scope of permissions can be granted by default to the callee by the caller in the host device. For example, if the caller's scope of permissions includes using the host device's gallery, network connectivity, location services, notification functions, and recipient information stored in the host device, then the caller can grant the callee permissions to use the host device's network connectivity and location services. Which permissions the caller in the host device grants to the callee by default can be defined or set in advance by the developer.

[0212] In some embodiments, the second permission scope can be granted by the user to the callee. The user can grant this second permission scope to the callee on the subject device or the object device; there is no limitation on this. This application embodiment does not limit the method by which the user grants the second permission scope to the callee; for example, the permission can be granted through a pop-up window, voice command, etc.

[0213] For example, refer to Figure 5D , Figure 5D This demonstrates a method by which a user grants permissions to a callee through the host device.

[0214] like Figure 5D As shown, the main device can display a user interface 54, which includes a prompt message 503, a control 504, and a control 505. This user interface 54 can be displayed by the main device before running the second instance. The prompt message 503 prompts the user whether to grant the callee (i.e., the FA providing the location function) permission to access the main device's location function. Control 504 can listen for user actions, and the main device can respond to these actions by granting the callee permission to access the location function within the main device. Control 505 can also listen for user actions, and the main device can respond to these actions by granting the callee permission to access the location function within the main device.

[0215] exist Figure 5D In the example shown, user interface 54 can be referred to as the third user interface, and user operations performed on control 504 can be referred to as third operations.

[0216] In the embodiments of this application, both the first permission scope and the second permission scope can be dynamically changed.

[0217] In this application embodiment, the process of the subject device and the object device communicating to access the first resource may include one or more of the following:

[0218] 1. The primary device runs a second instance within the second permission scope, accesses the second resource in the first resource, obtains a first access result, and sends the first access result to the secondary device. The secondary device runs a third instance and accesses the third resource in the first resource based on the first access result.

[0219] The definitions and examples of the first, second, and third resources can be found in the relevant descriptions above.

[0220] The first access result can be, for example, the main device accessing the positioning function, accessing memory resources, capturing images through the camera, or performing other operations; there are no restrictions here.

[0221] In some embodiments, when the object device runs a third instance and accesses a third resource in the first resource based on a first access result, a first user interface may be displayed based on the first access result. The content displayed in the first user interface includes the first access result or content processed based on the first access result.

[0222] For example, refer to Figure 5F , Figure 5F A third instance on the object device is shown, displaying a user interface 56 that shows the first access result (i.e., location data) obtained by running the second instance on the subject device. This user interface 56 is an example of the first user interface.

[0223] like Figure 5F As shown, user interface 56 is a location page for users to view the delivery person's location. Figure 5F The location data required for "My Location" displayed is obtained by the first part of the callee (i.e., the business logic part of the FA that provides the location function) running on the main device and sent to the main device.

[0224] In some embodiments, if in S106, the security policy corresponding to the second security domain identity assigned by the subject device to the second instance allows the second instance and the third instance to communicate, then the second instance in the subject device can send the acquired data to the third instance, and the object device can use the data to access the third resource in the first resource through the third instance.

[0225] In this embodiment of the application, since the first part of the caller and the callee share the same UID and are implemented as the same application, if the first instance and the second instance need to display the UI at runtime, they can be directly displayed through the same application without any poor presentation effect, thus ensuring the effect displayed to the user.

[0226] 2. In response to the access request, the object device runs a third instance, accesses the third resource in the first resource, obtains a second access result, and sends the second access result to the subject device. Afterwards, the subject device runs a second instance within the second permission scope and accesses the second resource in the first resource based on the second access result.

[0227] The definitions and examples of the first, second, and third resources can be found in the relevant descriptions above.

[0228] The second access result can be, for example, the main device accessing the positioning function, accessing memory resources, capturing images through the camera, or performing other operations; there are no restrictions here.

[0229] In some embodiments, when the main device runs the second instance and accesses the second resource in the first resource based on the second access result, it may display a UI, provide voice broadcasts, or perform further calculations or internal processing operations based on the second access result, etc., without any limitations.

[0230] As can be seen, in the embodiments of this application, the process of the caller calling the callee to access the first resource involves communication between the subject device and the object device, that is, data interaction between the subject device and the object device.

[0231] In S108, the primary device runs a second instance within the second permission scope. This minimizes the permissions of the first instance of the callee, preventing it from exploiting the caller's permissions to access sensitive resources of the primary device, thereby preventing data leakage from the primary device and ensuring data security. For example, in Figures 5A-5D In this example, the user grants the callee permission to access the location function on the main device, but does not grant the callee permission to access the recipient information stored on the main device. Therefore, when the main device is running a food delivery app, the instance of the business logic part of the FA providing the location function cannot obtain the recipient information stored on the main device, thus avoiding information leakage.

[0232] In some embodiments, if the second security policy in S106 is implemented as the above-mentioned case (2) or (3), or if the first security policy is implemented as the above-mentioned case (1) or (3), then during the operation of the second instance by the main device, the communication between the second instance and the first instance is restricted, and the second instance cannot receive the data obtained by the first instance using its own permissions. In this way, sensitive data in the main device can be prevented from being transmitted to the object device, thus ensuring the data security in the main device.

[0233] In some embodiments, if the second security policy in S106 is implemented as the above-mentioned case (2) or (4), or if the first security policy is implemented as the above-mentioned case (1) or (2), then during the operation of the second instance by the main device, the communication between the second instance and the first instance is restricted, and the second instance cannot send the data it has obtained to the first instance. This can prevent sensitive data in the object device from being transmitted to the first instance in the main device, thus ensuring the data security in the object device.

[0234] In other words, through S106, it can be ensured that the data in the subject device that the first instance can obtain and the data in the object device that the third instance can obtain will not be leaked to each other, thereby ensuring the data security of the subject device and the object device.

[0235] Not limited to Figure 4AExemplary distributed systems, Figure 4A The method shown can also be applied to a single electronic device. For example, the electronic device may contain a caller, a first part of the callee, and a second part of the callee, and the caller and the first part of the callee may be integrated into a single application. In this case, the electronic device is both a subject device and an object device. Figure 4A The operations performed by the subject device and the object device respectively are all performed by the electronic device itself, and the communication steps between the subject device and the object device can be omitted. For details on how access control methods are implemented in a single electronic device, please refer to [reference needed]. Figure 4A This will not be described in detail here.

[0236] exist Figure 4A In the method shown, the subject device can be referred to as the first device, and the object device can be referred to as the second device.

[0237] On the other hand, targeting Figure 2B The scenario illustrated in the diagram where the callee provides services in the form of a third-party library is also addressed in this application embodiment, which provides a corresponding access control method. This method is applied to a standalone system containing a single electronic device. This electronic device is both the subject device and the object device. The electronic device is equipped with a caller and a third-party library, and the caller and the third-party library are integrated into a single application. This electronic device can also be referred to as the first device.

[0238] in:

[0239] Callers can refer to the previous text.

[0240] Third-party libraries are the callees that provide various functions. They can be libraries such as lib libraries, SDK libraries, or dynamic link libraries (.so files).

[0241] The caller that integrates third-party libraries forms a whole with the third-party libraries to the outside world. Users do not distinguish or perceive that the caller actually contains two parts.

[0242] In this access control method, the electronic device creates an instance for both the caller and the third-party library, assigning both instances the same user identity (UID). The electronic device can then run the instance created for the third-party library within the permissions corresponding to that library. Here, the instance created by the electronic device for the caller can be referred to as the first instance, and the instance created for the third-party library can be referred to as the second instance.

[0243] In this way, the caller and the third-party library share the same user identity (UID), meaning the electronic device only runs one application, without consuming additional system resources. Furthermore, by creating different instances, the electronic device can clearly distinguish between the caller and the third-party library, ensuring that each instance of the third-party library runs within its corresponding permission scope. This minimizes the third-party library's permissions and prevents issues such as the third-party library stealing data outside its authorized scope during subsequent calls to the callee. It also prevents the third-party library from leaking data from the electronic device to other devices, thus ensuring data security within the electronic device.

[0244] In some embodiments, the electronic device can also assign different security domain identities to instances of the caller and instances of the third-party library, and run these instances according to the access policies corresponding to their respective security domain identities. The access policy defines the rules and requirements for instances to access specific files or directories, and to communicate with other instances; its specific content is not limited here. Through these respective access policies, the security of the data accessible to the caller instance and the data accessible to the third-party library instance can be guaranteed, preventing the leakage of sensitive resources and ensuring data security within the electronic device.

[0245] When a third-party library and a caller are installed in an electronic device, what are the specific implementation steps of this access control method? Figure 4A The method shown is similar and can be found in the relevant descriptions, which will not be repeated here.

[0246] refer to Figure 4B , Figure 4B To implement the access control method provided in the embodiments of this application, the overall application operation model integrates the caller and the callee in the first part. For example... Figure 4B As shown, the electronic device can create separate instances for the caller and the callee's first-part / third-party library, but they share the same user identity. Furthermore, a separate security domain identity is assigned to each instance. This prevents the caller from escalating privileges and leaking data during the process of calling the callee.

[0247] refer to Figure 6A , Figure 6A This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device can be... Figure 1 Any electronic device in the distributed system 10 shown. This electronic device can be... Figure 4A The main device in the process can also be any of the individual electronic devices mentioned above.

[0248] The electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0249] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0250] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0251] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0252] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0253] The wireless communication function of electronic devices can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0254] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0255] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G in electronic devices. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0256] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0257] The wireless communication module 160 can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0258] In some embodiments, antenna 1 of the electronic device is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the electronic device to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

[0259] Electronic devices implement display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0260] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device may include one or N displays 194, where N is a positive integer greater than 1.

[0261] Electronic devices can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0262] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).

[0263] Random access memory can include static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), and double data rate synchronous dynamic random access memory (DDR SDRAM, such as fifth-generation DDR SDRAM, which is generally called DDR5 SDRAM). Non-volatile memory can include disk storage devices and flash memory.

[0264] Flash memory can be classified according to its operating principle, including NOR FLASH, NAND FLASH, 3D NAND FLASH, etc.; according to the level of the storage cell, including single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), etc.; and according to the storage specification, including universal flash storage (UFS) and embedded multimedia card (eMMC), etc.

[0265] The random access memory can be directly read and written by the processor 110. It can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data.

[0266] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct reading and writing by the processor 110.

[0267] Electronic devices can implement audio functions such as music playback and recording through audio modules 170, speakers 170A, receivers 170B, microphones 170C, headphone jacks 170D, and application processors.

[0268] The pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194.

[0269] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of the electronic device, in a different position than display screen 194.

[0270] In this embodiment, the processor 110 can be used to create an instance for both the caller and the first part of the callee, and assign the same user identity (UID) to both instances. Subsequently, the instance of the caller and the instance of the first part of the callee can run in the RAM of the electronic device.

[0271] In some embodiments, the processor 110 may also assign different security domain identities to the instance of the caller and the instance of the first part of the callee, and run the instance of the caller and the instance of the first part of the callee according to the access policy corresponding to their respective security domain identities.

[0272] In this embodiment, the processor 110 can be used to create an instance for the caller and the third-party library respectively when the electronic device is running a caller that integrates a third-party library, and assign the same user identity (UID) to both instances. Then, the instance of the caller and the instance of the third-party library can run in the RAM of the electronic device.

[0273] In some embodiments, the processor 110 may also assign different security domain identities to the caller instance and the third-party library instance, and run the caller instance and the third-party library instance according to the access policy corresponding to their respective security domain identities.

[0274] RAM, as an internal memory where the processor directly exchanges data, can be read and written at any time and is very fast. It is usually used as a temporary data storage medium for the operating system or other running programs.

[0275] In some embodiments, the internal memory 121 can be used to store the permissions corresponding to the instance of the caller, the instance of the third-party library, or the instance of the first part of the callee, respectively. This allows the electronic device to run the instance of the third-party library or the instance of the first part of the callee within the corresponding permission scope.

[0276] In some embodiments, the internal memory 121 may also store access policies corresponding to each security domain identity, so that the electronic device can run an instance of the caller, an instance of the third-party library, or an instance of the first part of the callee according to the access policy corresponding to the respective security domain identity.

[0277] The display screen 194 is used to display the user interface provided in the previous embodiments of this application.

[0278] refer to Figure 6B , Figure 6B This is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application. The electronic device can be... Figure 4A The main device in the process can also be any of the individual electronic devices mentioned above.

[0279] The software systems of electronic devices can adopt layered architectures, event-driven architectures, microkernel architectures, microservice architectures, or cloud architectures, etc. For example, the software systems of electronic devices include, but are not limited to, those mentioned above. Linux or other operating systems.

[0280] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0281] The application layer can include a series of application packages.

[0282] like Figure 6B As shown, the application package can include apps such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS applications. The application layer may also include functional components such as FA, PA, etc.

[0283] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0284] like Figure 6B As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0285] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0286] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0287] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0288] A phone manager is used to provide communication functions for electronic devices. For example, it manages call status (including connection and disconnection).

[0289] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0290] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0291] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0292] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0293] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0294] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0295] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0296] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0297] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0298] A 2D graphics engine is a graphics engine for 2D drawing.

[0299] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0300] refer to Figure 6C , Figure 6C This is a schematic diagram of the software structure of an electronic device provided in an embodiment of this application. The electronic device can be... Figure 4A The main device in the process can also be any of the individual electronic devices mentioned above.

[0301] like Figure 6C As shown, the electronic device may include the following modules: application information management module, application startup management module, instance management module, security domain management module, security domain policy management module, group management module, security policy library, and access control module.

[0302] The application information management module is used to manage information about the various apps and functional components installed on electronic devices. This includes managing the names of each app and component. The module also synchronizes information about apps and components on the device to other devices, and receives synchronized information about apps and components from other devices.

[0303] The application startup management module is used to manage the startup process of various apps and functional components.

[0304] The instance management module is used to create an instance for the first part of both the caller and the callee when the caller invokes the callee, and to assign the same user identity (UID) to both instances.

[0305] The instance management module is also used to create an instance for both the caller and the third-party library when the caller invokes the third-party library, and to assign the same user identity (UID) to both instances.

[0306] The instance management module is also used to manage the lifecycle of each created instance, such as starting, stopping, destroying, and restarting.

[0307] The security domain management module is used to assign security context information to each instance so that the kernel can create the corresponding kernel security domain. Specifically, this module can assign different security domain identities to the caller instance and the first part of the callee instance. This module can also assign different security domain identities to the caller instance and the third-party library instance.

[0308] The security domain policy management module is used to provide security policies corresponding to the identities of each security domain, which are then loaded and enabled by the kernel-level security domains.

[0309] The security policy library stores the security policies corresponding to the identities of each security domain. For example, it may include allowing the logic code instance of the FA to communicate with the UI instance of the FA, and denying the logic code instance of the FA from communicating with the caller instance, etc.

[0310] The group management module is used to add, modify, and delete group information for instances of the callee's first part or third-party libraries. Specifically, based on the permissions requested and granted by the caller to the callee, corresponding group ID information is assigned to instances of the callee's first part or third-party libraries. This group ID information is also updated synchronously when the caller's permissions change dynamically. Members within the group identified by this group ID have permission to access instances of the callee's first part or third-party libraries.

[0311] The access control module is used to control access to device resources based on the permissions of the caller instance, the callee instance (first part), or the third-party library instance. Specifically, this access control module can perform instance-level permission control based on the permission information granted by the caller to the callee instance (first part) or the third-party library instance, allowing only the callee instance (first part) or the third-party library instance to run within the corresponding permission scope.

[0312] Figure 6C This is merely an illustrative example; the electronic device provided in this application embodiment may also include more or fewer modules, and no limitation is made here.

[0313] Figure 6C The modules of the electronic device shown can be located in Figure 6B The application framework layer, system service layer, kernel layer, etc. of electronic devices are not limited here.

[0314] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0315] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0316] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0317] In summary, the above description is merely an embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made according to the disclosure of the present invention should be included within the scope of protection of the present invention.

Claims

1. An access control method characterized by, The method is applied to a first device, which has a caller installed. The caller is an app or a functional component, wherein the app is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function; the method includes: The first device creates a first instance of the caller and runs the first instance within the scope of the first permissions; During the operation of the first instance, the first device generates an access request. The access request is used by the caller to call the callee to access the first resource. The callee is the APP or the functional component. The callee is deployed in the first device and / or the second device. The first resource includes resources in the first device and / or the second device. The first device creates a second instance of the callee and runs the second instance within a second permission scope to access the first resource; the second instance and the first instance have the same user identity UID, but the second permission scope is different from the first permission scope.

2. The method of claim 1, wherein, The callee comprises a first part and a second part, wherein the first part is deployed in the first device and the second part is deployed in the second device; The first resource includes resources in the first device and the second device; Before the first device accesses the first resource, the method further includes: the first device sending the access request to the second device; The first device creates a second instance of the callee and runs the second instance within the second permission scope to access the first resource, specifically including: The first device creates a second instance of the first part of the callee; During the process of the first device running the second instance within the second permission scope, and during the process of the second device running the third instance, the first device and the second device communicate to access the first resource; the third instance is an instance of the second part of the callee created by the second device in response to the access request.

3. The method of claim 2, wherein, During the process of the first device running the second instance within the second permission scope, and during the process of the second device running the third instance, the first device and the second device communicate to access the first resource, specifically including: The first device runs the second instance within the second permission scope, accesses the second resource in the first resource, obtains the first access result, and sends the first access result to the second device, so that the second device runs the third instance and accesses the third resource in the first resource according to the first access result.

4. The method of claim 3, wherein, The first part of the callee is used to implement business logic, and the second part of the callee is used to provide a UI; the first access result is used by the second device to display the first user interface when running the third instance.

5. The method of claim 2, wherein, During the process of the first device running the second instance within the second permission scope, and during the process of the second device running the third instance, the first device and the second device communicate to access the first resource, specifically including: The first device receives the second access result, which is obtained by the second device responding to the access request by running a third instance and accessing the third resource in the first resource; The first device runs the second instance within the second permission scope and accesses the second resource in the first resource according to the second access result.

6. The method of claim 2, wherein, After the first device sends the access request to the second device, the method further includes: The first device sends the second part of the callee to the second device.

7. The method of claim 1, wherein, The called party is a third-party library, which is deployed in the first device, and the first resource includes the resources in the first device; The first device creates a second instance of the callee and runs the second instance within the second permission scope to access the first resource, specifically including: The first device creates a second instance of the third-party library and runs the second instance within the second permission scope to access the first resource.

8. The method of claim 7, wherein, The third-party library is a software development kit (SDK) library or a dynamic link library.

9. The method according to any one of claims 1-7, characterized in that, After the first device creates a first instance of the caller, the method further includes: The first device assigns a first security domain identity to the first instance, and the first access policy corresponding to the first security domain identity indicates that: the first instance and the second instance are not allowed to communicate, or the first instance is not allowed to send data to the second instance, or the first instance is not allowed to receive data sent by the second instance. The first device runs the first instance within the first permission scope, specifically including: the first device runs the first instance according to the first access policy within the first permission scope; And / or, After the first device creates a second instance of the callee, the method further includes: The first device assigns a second security domain identity to the second instance, and the second access policy corresponding to the second security domain identity indicates that: the second instance is not allowed to communicate with the first instance, or the second instance is not allowed to send data to the first instance, or the second instance is not allowed to receive data sent by the first instance. The first device runs the second instance within the second permission scope, specifically including: the first device runs the second instance according to the second access policy within the second permission scope.

10. The method according to any one of claims 1-7, characterized in that, After the first device creates a first instance of the caller, the method further includes: the first device assigning a first UID and a first process identifier PID to the first instance; After the first device creates a second instance of the callee, the method further includes: the first device assigning a first UID and a second PID to the second instance.

11. The method according to any one of claims 1 to 7, characterized in that, Before the first device creates the first instance of the caller, the method further includes: The first device detects a first operation used to initiate the caller.

12. The method according to any one of claims 1-7, characterized in that, Before generating an access request during the operation of the first instance by the first device, the method further includes: The first device displays a second user interface; The first device receives a second operation on the second user interface.

13. The method according to any one of claims 1-7, characterized in that, The second permission scope is a portion of the first permission scope; or, Before the first device runs the second instance within the second permission scope, the method further includes: The first device displays a third user interface; The first device receives a third operation on the third user interface; In response to the third operation, the first device determines the second permission scope.

14. An electronic device, comprising: include: A memory and one or more processors; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors calling the computer instructions to cause the electronic device to execute: Create a first instance of the caller and run the first instance within a first permission scope; the caller is an APP or a functional component, the APP is a program entity that implements multiple functions, and the functional component is a program entity that implements a single function; During the execution of the first instance, an access request is generated. The access request is used by the caller to call the callee to access the first resource. The callee is the APP or the functional component. The callee is deployed in the electronic device and / or the second device. The first resource includes resources in the electronic device and / or the second device. Create a second instance of the callee, and run the second instance within the second permission scope to access the first resource; The second instance and the first instance have the same user identity UID, but the second permission scope is different from the first permission scope.

15. The electronic device of claim 14, wherein, The callee comprises a first part and a second part, the first part being deployed in the electronic device and the second part being deployed in the second device; the first resource includes resources in the electronic device and the second device; The one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: sending the access request to the second device before accessing the first resource; The one or more processors are specifically used to invoke the computer instructions to cause the electronic device to execute: Create a second instance of the first part of the callee; During the execution of the second instance within the second permission scope, and during the execution of the third instance on the second device, communication is established with the second device to access the first resource; The third instance is an instance of the second part of the callee created by the second device in response to the access request.

16. The electronic device of claim 15, wherein, The one or more processors are specifically used to invoke the computer instructions to cause the electronic device to execute: The second instance is run within the second permission scope, accesses the second resource in the first resource, obtains the first access result, and sends the first access result to the second device, so that the second device runs the third instance and accesses the third resource in the first resource according to the first access result.

17. The electronic device of claim 16, wherein, The first part of the callee is used to implement business logic, and the second part of the callee is used to provide a UI; the first access result is used by the second device to display the first user interface when running the third instance.

18. The electronic device of claim 15, wherein, The one or more processors are specifically used to invoke the computer instructions to cause the electronic device to execute: Upon receiving the second access result, the second access result is obtained by the second device in response to the access request, running the third instance and accessing the third resource in the first resource; Run the second instance within the second permission scope, and access the second resource in the first resource based on the second access result.

19. The electronic device of claim 15, wherein, The one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: After sending the access request to the second device, the second part of the callee is sent to the second device.

20. The electronic device of claim 14, wherein, The called party is a third-party library, which is deployed in the electronic device. The first resource includes resources in the electronic device. The one or more processors are specifically used to invoke the computer instructions to cause the electronic device to execute: Create a second instance of the third-party library and run the second instance within the second permission scope to access the first resource.

21. The electronic device of claim 20, wherein, The third-party library is a software development kit (SDK) library or a dynamic link library.

22. The electronic device according to any one of claims 14-21, characterized in that, The one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: After creating the first instance of the caller, a first security domain identity is assigned to the first instance. The first access policy corresponding to the first security domain identity indicates that: the first instance and the second instance are not allowed to communicate, or the first instance is not allowed to send data to the second instance, or the first instance is not allowed to receive data sent by the second instance. The one or more processors are specifically configured to invoke the computer instructions to cause the electronic device to execute: within a first permission scope, running the first instance according to the first access policy; And / or, The one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: After creating the second instance of the callee, a second security domain identity is assigned to the second instance. The second access policy corresponding to the second security domain identity indicates that: the second instance is not allowed to communicate with the first instance, or the second instance is not allowed to send data to the first instance, or the second instance is not allowed to receive data sent by the first instance. The one or more processors are specifically configured to invoke the computer instructions to cause the electronic device to execute: within the second permission scope, running the second instance according to the second access policy.

23. The electronic device of any of claims 14-21, wherein, The one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: After creating the first instance of the caller, a first UID and a first process identifier PID are assigned to the first instance; After creating a second instance of the callee, the first UID and the second PID are assigned to the second instance.

24. The electronic device of any of claims 14-21, wherein, The one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: Before the first instance of the caller is created, a first operation for initiating the caller is detected.

25. The electronic device according to any one of claims 14-21, characterized in that, The one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: During the execution of the first instance, before generating an access request, a second user interface is displayed; The second operation is received on the second user interface.

26. The electronic device according to any one of claims 14-21, characterized in that, The second permission scope is a portion of the first permission scope; or, The one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: A third user interface is displayed before the second instance is run within the second permission scope; A third operation is received on the third user interface; In response to the third operation, the second permission scope is determined.

27. A computer-readable storage medium comprising instructions, wherein: When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-13.

28. A computer program product, characterised in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-13.

Images