Isolation of application-specific data within a user account

Traditionally, operating systems provide application-specific data at the granularity of user accounts.<u style="single">isolation</u>To do. That is, applications running under different user accounts are mutually exclusive.<u style="single">isolation</u>Will be done. As a result, an application running under one user account cannot access data for the same application running under another user account. However, the data for applications running under the same user account are mutually exclusive.<u style="single">isolation</u>Not done. As a result, an application running under one user account can even access and modify data for another application running under the same user account. This can pose potential stability, security and management issues. Therefore, application-specific data between applications that share the same user account<u style="single">isolation</u>It is hoped that a mechanism for this will be provided.

<p> In the detailed explanation, this outline is provided in order to introduce an extract of the concept described later in a simplified format. This summary is not intended to identify important features of the claimed object, nor is it intended to be used as an aid in determining the scope of the claimed object.</p><p> In an environment where multiple applications are associated with the same user account, the present invention allows application-specific data from another application.<u style="single">isolation</u>it can. For example, the present invention uses a handle-based approach to access data. If an application owns a handle to the data, it can access the data. If the data is application-specific, you can generate only one handle for that data. The handle is passed to the application identifying the data. Only the application that owns the handle can access the data. Access requests from other applications that share the same user account with the application are denied.</p><p> According to one feature of the invention, when the application needs to access the data and the data is not loaded, the data is loaded first. Desirably, a unique identifier is generated for the data. The unique identifier is then used to form an access route for the data. The access route indicates where the data can be loaded. The data will be loaded to that location. Handles are generated for the loaded data and passed to the application. The application can access the data through the handle. If only one application has access to the data, then that data is considered specific to that application. No other application that shares the same user account with that application can generate a handle for the loaded data and cannot access the data through the handle. On the other hand, if the data is not application-specific, another application can generate a handle to the data and access the data through that handle.</p><p> According to another feature of the invention, when data is loaded, a counter is generated for that data. Increase the value of the counter each time a handle is created for that data, and decrease it each time the handle for that data is terminated. When the counter value reaches 0, the data is automatically unloaded.</p><p> A further feature of the invention provides an application programming interface for application-specific data access. In an environment where multiple applications share the same user account, the application programming interface includes a computational process, that is, the ability to provide access to data objects when an access request is received from the application. This function can be configured so that the data object can only be accessed by the computational process requesting access. That is, another calculation process cannot access the data object. Desirably, the function includes parameters that can be configured so that only the computational process currently calling the function can access the data object. The parameters can also be configured so that any calculation process that calls this function to access the data object can access the data object.</p><p> More specifically, when called by a computational process requesting access to a data object, the feature will generate a unique identifier for that data object. The unique identifier can then be used to generate a path that points to the location for loading the data object. The function then loads the data object accordingly. The function then returns a handle to the loaded data object to the calculation process. Each time the calculation process completes an access request, it terminates the corresponding handle. When there are no more handles associated with a data object, this function unloads that data object.</p>

<p> In summary, the present invention can prevent application-specific data from being accessed by another application that shares the same user account with said application. According to the present invention, application-specific data can be accessed only by the application. Another application thus sharing the same user account with the application cannot interfere with the integrity of the application-specific data.</p><p> Many of the above features and the advantages of the attachments of the present invention will be more easily and correctly evaluated, as the equivalent will be further understood by reference to the following detailed description when used in conjunction with the accompanying drawings. Will come to be.</p>

Generally speaking, embodiments of the present invention provide application-specific data between applications associated with the same user account.<u style="single">isolation</u>To do. More specifically, embodiments of the present invention employ a handle-based approach for accessing data in an environment where multiple applications are associated with the same user account. When an application needs to access application-specific data, that data is loaded, handles are generated for the data, and passed to the application. The application accesses the data through the handle. Another application cannot generate a handle for that data and therefore access to that data is denied. In embodiments of the invention, the data may include any data that may be used by applications that share the same user account.

Figure 1 illustrates a computer system (100) hosting multiple applications for the user (101). Multiple applications include application A (102A) and application B (102B). In this illustrated example, application data A (104A) is specific to application A (102A), while application data B (104B) is specific to application B (102B). In the embodiment of the present invention, when an access request is received from the application for the data object peculiar to the application, the unique identifier (UID) is dynamically generated. The UID is used to generate an access route for a data object. For example, once application A (102A) requests application data A (104A), UID A (106A) is dynamically generated. UID A (106A<u style="single">) Is</u>It can then be used to generate an access route such as / root / app / UID A / Application Data A and can be used to load application data A (104A) into the location specified by that access route. Similarly, when application B (102B) wants to access application data B (104B), the computer system (100) dynamically generates UID B (106B), where UID B is application data B. Used to form an access route for (104B). Such an access route can be, for example, / root / app / UID B / Application Data B. Application data B (104B) can be loaded in the location specified by the access route.

In the embodiment of the present invention, after generating the route corresponding to the UID and the access for the data object specific to the application, the computer system (100) loads the data object at the location specified by the access route. The computer system (100) then creates a handle for the loaded data object and passes that handle to the application requesting the data object. For example, as shown in FIG. 1, application A (102A) receives handle A (110A) to application data A (104A). Application B (102B) receives handle B (110B) to application data B (104B). In an embodiment of the invention, only an application that owns a handle to a data object can access the data object, and only an application that explicitly identifies the data object can own a handle to that data object. Therefore, in the example illustrated in FIG. 1, only application A (102A) can access application data A (104A) and only application B (102B) can access application data B (104B).

Theoretically, another application can access the data object through that access path. In an embodiment of the invention, if an application attempts to access a data object through its access path, that access is denied. For example, as described above, the access route for application data A (104A) is / root / app / UID A / Application Data A. Theoretically, application B (102B) can access application data A (104A) through this access path. In an embodiment of the invention, such access is denied and access is only allowed to application data A (104A) via handle A (110A). Thus, only application A (102A) can access application data A (A104).

Embodiments of the present invention also provide counters for loaded data objects. Handle is generated for the data object loaded whenever Ru, increase the value of the counter. Decrease the value of the counter each time the handle to the loaded data object is terminated. In an embodiment of the invention, when the counter value reaches 0, the corresponding data object is unloaded. For example, as shown in FIG. 1, the loaded application data A (104A) is associated with the counter (112A) and the loaded application data B (104B) is associated with the counter (112B). In an embodiment of the invention, when one data object is loaded, another application cannot replace the loaded data object with another data object.

In an exemplary embodiment of the invention, the computer system (100) uses a Microsoft® Windows® operating system. As is known by those skilled in the art, the Microsoft® Windows® operating system uses the Windows® Registry as a central repository for system and user-related data. On disk, the Windows Registry is organized as a set of individual files, data objects, called a hive. Each hive contains a hierarchical structure of data. When the hive is loaded into the computer system's file system, the access route to the hive is recorded under HKEY LOCAL MACHINE / SYSTEM / CurrentControlSet / Control / hivelist. When the hive is unloaded, the access route is deleted.

Now, when the Microsoft® Windows® operating system starts, the Windows® Registry loads some hives by default. Traditionally, the RegLoadKey API has been used to allow users to load certain hives on demand. When the hive is loaded using the RegLoadKey API, the hive becomes visible throughout the system. As a result, anyone with sufficient access rights can access the hive data. However, the RegLoadKey API does not allow ordinary users to load hives without the need for privileges. The RegLoadKey API also does not prevent another application running under the same user account from manipulating the data in the hive.

To resolve the limitations imposed by the RegLoadKey API, exemplary embodiments of the invention provide, for example, a novel hybrid API called RegLoadAppKey. The RegLoadAppKey API allows users to load hives without the need for privileges. The RegLoadAppKey API is also an application-level hive loaded using this API.<u style="single">isolation</u>Also enable. Unlike the existing RegLoadKey API, which loads a hive with system-wide visibility, the RegLoadAppKey API loads a hive with only process-wide visibility. That is, only the process that calls the RegLoadAppKey API gets a handle to the hive. The RegLoadAppKey API exposes the hive only to the first process that successfully loads the hive. Using the RegLoadAppKey API in this way, an application can load a hive that contains settings that are relevant only to that application, and no other application running under the same or different user accounts can access this hive. Can be guaranteed. The hive is automatically unloaded at the end of the application or when the last reference to the handle associated with the hive is closed.

Figure 2 illustrates an exemplary usage of the RegLoadAppKey API (200). When an application (202) calls the RegLoadAppKey API (200) to load a particular hive, the application (202) provides the RegLoadAppKey API (200) with the filename of the hive to be loaded. According to the provided file name, RegLoadAppKey API (200) loads the specified hive and conversely provides the hive handle (204) to the application (202). Application (202) can then manipulate the loaded hive via handle (204).

In an exemplary implementation of the RegLoadAppKey API (200), the RegLoadAppKey API (200) will generate a UID (206) when it receives the filename of the hive to be loaded. If the hive is already loaded, the UID (206) will be ignored. Otherwise, the UID (206) is used to form the "route to where to load" (208) and indicates where the hive can be loaded. For example, you can load a hive into / registry / app / UID.

In an exemplary embodiment of the invention, RegLoadAppKey (200) can then call the NtLoadKeyEx API (210) to load the hive. The NtLoadKeyEx API (210) loads the hive to the location specified by "Route to location to load" (208) and returns a handle (204) for the hive. Desirably, every time the application (202) calls the RegLoadAppKey API (200) to access the hive, a handle for the hive (204) is generated. When application (202) gives up access, the corresponding handle is closed. The hive is automatically unloaded when all the handles for the hive are closed.

Operationally, the RegLoadAppKey API (200) can include parameters to specify that access to the hive is limited to the called application (202). If a parameter is specified, then attempts by another application to load the same hive will fail, making the hive accessible only to the application (202) that loaded it in this way. If no parameter is specified, multiple applications, or processes, can load the same hive. In addition, if an access request attempts to access the hive through the "route to where to load" (208) instead of from the handle for the hive (204), the RegLoadAppKey API (200) will use that access request. Reject.

Figures 3A and 3B show application-specific data from another application that shares the same user account with that application.<u style="single">isolation</u>An exemplary process (300) for this is shown. In essence, when data is unloaded, process (300) loads the requested data, creates a handle to the loaded data, and passes the handle to the application requesting that data. Process (300) also uses a counter to keep track of the number of handles associated with the data. Increase the value of the counter each time a handle is generated for the data, and decrease it each time the application terminates the handle associated with the data. When the counter value reaches 0, the data is automatically unloaded. In particular, an application can load data under specifications that no other application can access the data. In such a case, the access request from another application is denied.

Specifically, as shown in Figure 3A, when Application A requests access to some data, process (300) is started. See judgment block (301). In an exemplary embodiment of the invention, when such a request is received, process (300) generates a unique identifier for the data. See block (302). Process (300) then uses the unique identifier to generate an access route for the data. See block (304). As described above, for example, the access route for application data A (104A) having UID A (106A) is / Root / App / UID A / Application Data A.

Process (300) then proceeds to determine if the data has already been loaded by another application. See judgment block (305). If the answer to the decision block (305) is affirmative, the process (300) then decides whether the loaded data is application-specific, that is, only the application that loaded the data can access the data. move on. See judgment block (306). If the answer to the decision block (306) is affirmative, it means that the data is application-specific and loaded by another application, and process (300) terminates. The access request from application A is denied.

If the answer to the decision block (306) is negative, it means that the data can be accessed by multiple applications, and the process (300) generates a handle to the loaded data. block(<u style="single">309</u>).

On the other hand, if the answer to the decision block (305) is negative, it means that the data has not been loaded by any application, and the process (300) loads the data to the location specified by the generated access path. To do. See block (307). Process (300) then generates a counter associated with the loaded data. See block (308). The initial value of the counter is set to 0. Process (300) then creates a handle to the data. See block (309). Process (300) passes the handle to the application. See block (310). Process (300) continues from block (310) to continuation terminal A.

In embodiments of the invention, if the data is application specific, only one handle will be generated for the data and only the application that owns the handle will be able to access the data. Another application has no handle on the data and therefore cannot access that data. As mentioned above, theoretically another application can access the data through the generated access path. However, an embodiment of the present invention denies access to data via that access route. Therefore, only the application that owns the handle to the data can access the data.

In embodiments of the invention, counters are used to keep track of the number of handles associated with the loaded data. Increases the value of the counter each time a handle is generated for loaded data and decreases each time a handle to the data is terminated. When the counter value reaches 0, the data is automatically unloaded. As a result, the counter is incremented when a handle is generated for the data, as illustrated in FIG. 3B from continuation terminal A. See block (314). In addition, when the handle to the data is terminated, the value of the counter is decremented. See block (316). In an embodiment of the invention, the process (300) periodically checks the value of the counter to determine if it has reached zero. See judgment block (318). When the value of the counter reaches 0, it means that there is no handle associated with that data, and process (300) unloads the data. See block (320). If the answer to the decision block (318) is negative, it means that the value of the counter is non-zero, and the process (300) loops back to block (314) to wait for any adjustment of the counter value. Once the data is unloaded, process (300) terminates.

As a result, embodiments of the present invention provide application-specific data that runs under the same user account.<u style="single">isolation</u>To do. Embodiments of the present invention also automatically unload the data object once the last reference to the data object is closed.

Although exemplary embodiments of the invention have been shown and described, it will be well understood that various modifications to the present specification can be made without departing from the spirit and scope of the invention.

<figref num="1">It is a block diagram showing an exemplary computer system for implementing the features of the present invention, and application-specific data is provided for a plurality of applications having the same user account.<u style="single">isolation</u>Will be done.</figref><figref num="2">FIG. 6 is a block diagram showing an exemplary Windows® API for implementing the features of the present invention.</figref><figref num="3A">Application-specific data within a user account<u style="single">isolation</u>It is a flow diagram which shows the exemplary process for doing.</figref><figref num="3B">Application-specific data within a user account<u style="single">isolation</u>It is a flow diagram which shows the exemplary process for doing.</figref>