Virtual directory creation methods and electronic devices

Abstract

This application provides a method for creating a virtual directory and an electronic device, relating to the field of operating systems. The virtual directory creation method provided in this application modifies the access paths for file operations passed by user-level applications and / or users during the parsing of access paths by the virtual file system, thereby achieving data isolation between different applications and / or users.

Description

Technical Field

[0001] This application relates to the field of operating systems, and in particular to methods for creating virtual directories and electronic devices. Background Technology

[0002] With the development of electronic technology, more and more electronic devices are becoming integrated into users' daily lives. Users can install multiple applications on their electronic devices to meet the different needs of different users.

[0003] However, most existing operating systems, such as Linux and Android, cannot achieve strict data isolation, which means that application and / or user data may be modified by other applications and / or users, leading to attacks on application data and failure to function properly, and may further result in the leakage of user information.

[0004] For example, when an electronic device assigns storage permissions to application 1 and application 2 on external storage, such as the storage permissions of a secure digital memory card (SD card), application 1 can read / modify the data stored in external storage by application 2, and application 2 can also read / modify the data stored in external storage by application 1.

[0005] Clearly, the aforementioned problem arises because the permissions provided by the operating system only indicate whether an application can read / write data in external storage. Summary of the Invention

[0006] This application provides a method for creating a virtual directory and an electronic device. The virtual directory creation method provided in this application modifies the access paths for file operations passed by user-level applications and / or users during the parsing of access paths in the virtual file system, thereby achieving data isolation between different applications and / or users.

[0007] In a first aspect, embodiments of this application provide a method for establishing a virtual directory. The method includes: a first application performing an open operation on a first file through a first system call; an operating system obtaining a first path through the first system call; after determining that the first application meets a first condition, the operating system determines a direct path corresponding to the first path based on the first path and a starting directory, the direct path being used to determine the location of the first file in the file view of the first application, the starting directory being the process root directory or the current working directory; after determining that the direct path meets a second condition, the operating system determines a real path based on the direct path and the virtual directory corresponding to the first application; after locating the first file based on the real path, the operating system returns the file descriptor of the first file to the first application.

[0008] In the above embodiments, during the process of resolving the access path in the virtual file system, the access path for file operations passed by the user-level application and / or user is modified so that only the application and / or user can obtain the file descriptor of the file in the virtual directory, and thus be able to perform read or write operations on the file.

[0009] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes: a first application performing a read operation or a write operation on a first file through a second system call; after the operating system obtains a second path and a file descriptor through the first system call, the operating system determines the second path as an indirect path; the operating system determines the direct path based on the file descriptor of the first file and the second path; after the operating system determines that the direct path satisfies the second condition, the operating system determines the real path based on the direct path and the virtual directory corresponding to the first application; after the operating system locates the first file based on the real path, it performs the read operation or the write operation.

[0010] In the above embodiments, during the process of performing write or read operations on a file, the operating system's virtual file system cannot determine whether the call is a first system call or a second system call. Therefore, it is necessary to combine the file descriptor to determine whether the access path is a direct path or an indirect path, and then determine how to modify the access path to obtain the real path, and then perform the corresponding operation after locating the file.

[0011] In conjunction with some embodiments of the first aspect, in some embodiments, the first application performs a read operation or a write operation on the first file through a second system call; after the operating system obtains the second path and the file descriptor through the first system call, and determines that the second path satisfies the second condition, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application; after the operating system determines to execute the function for resolving the file descriptor, the operating system restores the third path to the second path, and the operating system determines the direct path according to the file descriptor of the first file and the second path; after the operating system determines that the direct path satisfies the second condition, the operating system determines the real path based on the direct path and the virtual directory corresponding to the first application; after the operating system locates the first file based on the real path, it performs the read operation or the write operation.

[0012] In the above embodiments, the operating system's virtual file system cannot determine whether the call is a first system call or a second system call, and therefore does not know whether the access path is a direct path or an indirect path. It first performs processing according to the direct path, and then determines whether it is an indirect path based on whether the file descriptor resolution function is entered. If it is an indirect path, it restores the processing, and then modifies the access path according to the processing logic of the indirect path. After locating the file, it performs the corresponding operation.

[0013] In conjunction with some embodiments of the first aspect, in some embodiments, the first application performs a read operation or a write operation on the first file through a second system call; after the operating system obtains the second path and the file descriptor through the first system call, and determines that the second path satisfies the second condition, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application; after the operating system determines that it will not execute the function used to parse the file descriptor, the third path becomes the real path; after the operating system locates the first file based on the third path, it performs the read operation or the write operation.

[0014] In the above embodiments, the operating system's virtual file system cannot determine whether the call is a first system call or a second system call, and therefore does not know whether the access path is a direct path or an indirect path. It first performs processing as a direct path, and then determines whether it is a direct path based on whether the file descriptor resolution function is entered. After locating the file, it performs the corresponding operation.

[0015] In conjunction with some embodiments of the first aspect, in some embodiments, the operating system obtains the first string path sent by the first application through the first system call, and the operating system converts the first string into a filename structure, the filename structure including a first symbol pointer and a first field; during the process of the operating system converting the first string into a filename structure, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application; the operating system stores the third path at the physical address pointed to by the first symbol pointer, and the operating system stores the second path in the first field.

[0016] In the above embodiments, by modifying the structure of the filename structure, the filename structure can store the access paths before and after the modification, so that the modification is not an overwrite modification. This allows the modified access path to be quickly restored when it is necessary to restore the modified access path.

[0017] In conjunction with some embodiments of the first aspect, in some embodiments, the first file is a symbolic link file, the content of the first file includes a fourth path, the fourth path being used to indicate the second file; the method further includes: the operating system parsing the first file to obtain the fourth path; the operating system determining a fifth path based on the fourth path and the virtual directory corresponding to the first application, the fifth path being used to locate the second file.

[0018] In the above embodiments, when the file is a symbolic link file, since the content of the symbolic link file points to the path of other files, it is necessary to modify the path indicated by the symbolic link file again to prevent sandbox escape.

[0019] In conjunction with some embodiments of the first aspect, in some embodiments, before the operating system determines the fifth path based on the fourth path and the virtual directory corresponding to the first application, the method further includes: the operating system requesting first storage resources to store the fourth path; after the operating system determines the fifth path based on the fourth path and the virtual directory corresponding to the first application, the method further includes: the operating system releasing the storage resources occupied by the fifth path;

[0020] In the above embodiments, since the path indicated by the content of the symbolic link file needs to be modified, the memory allocation and release functions need to be reconfigured to avoid insufficient memory for the storage path or to avoid memory waste caused by the path indicated by the content of the symbolic link file not being released in time.

[0021] In conjunction with some embodiments of the first aspect, in some embodiments, after the operating system determines that the user identifier has switched from the first user identifier to the second user identifier, it switches the current working directory to the working directory corresponding to the second user identifier; after the operating system determines that the application identifier has switched from the first application identifier to the second application identifier, it switches the current working directory to the working directory corresponding to the second application identifier.

[0022] In the above embodiments, when a user or application switches, the current working directory needs to be switched simultaneously to prevent sandbox leaks. For example, if application 1 switches to application 2, and the current working directory is not switched, then application 2 can actually access the data of application 1 after switching to application 2.

[0023] In some embodiments of the first aspect, the operating system receives a sixth path sent by the first application. After determining that the sixth path satisfies the second condition, the operating system inserts a virtual directory corresponding to the first application into the sixth path to obtain a seventh path. Before storing the seventh path, the operating system determines that the seventh path has been inserted into the virtual directory corresponding to the first application, then restores the seventh path to the sixth path and stores the sixth path. When a third application uses the sixth path through a third system call, the operating system reads the sixth path and inserts a virtual directory corresponding to the third application into the sixth path to obtain a seventh path. The operating system then performs the operation corresponding to the third system call based on the seventh path.

[0024] In the above embodiment, the path sent by application 1 is first modified to the real path, and then restored to the path sent by application 1 before being saved. This allows the virtual file system to add the virtual directory corresponding to the application in the path when other applications use it.

[0025] Secondly, embodiments of this application provide an electronic device, comprising: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is 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: a first application performs an open operation on a first file through a first system call; an operating system obtains a first path through the first system call, and after determining that the first application meets a first condition, the operating system determines a direct path corresponding to the first path based on the first path and a starting directory, the direct path being used to determine the location of the first file in the file view of the first application, the starting directory being the process root directory or the current working directory; after determining that the direct path meets a second condition, the operating system determines a real path based on the direct path and a virtual directory corresponding to the first application; after locating the first file based on the real path, the operating system returns the file descriptor of the first file to the first application.

[0026] In the above embodiments, during the process of resolving the access path in the virtual file system, the access path for file operations passed by the user-level application and / or user is modified so that only the application and / or user can obtain the file descriptor of the file in the virtual directory, and thus be able to perform read or write operations on the file.

[0027] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: a first application performs a read operation or a write operation on a first file through a second system call; after the operating system obtains a second path and the file descriptor through the first system call, the operating system determines the second path as an indirect path; the operating system determines the direct path based on the file descriptor of the first file and the second path; after the operating system determines that the direct path satisfies the second condition, the operating system determines the real path based on the direct path and the virtual directory corresponding to the first application; after the operating system locates the first file based on the real path, it performs the read operation or the write operation.

[0028] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: a first application performs a read operation or a write operation on a first file through a second system call; after the operating system obtains a second path and the file descriptor through the first system call, and determines that the second path satisfies the second condition, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application; after the operating system determines to execute a function for resolving the file descriptor, the operating system restores the third path to the second path, and the operating system determines the direct path according to the file descriptor of the first file and the second path; after the operating system determines that the direct path satisfies the second condition, the operating system determines the real path based on the direct path and the virtual directory corresponding to the first application; after the operating system locates the first file based on the real path, it performs the read operation or the write operation.

[0029] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: a first application performs a read operation or a write operation on a first file through a second system call; after the operating system obtains a second path and the file descriptor through the first system call, and determines that the second path satisfies the second condition, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application; after the operating system determines that it will not execute the function used to parse the file descriptor, the third path becomes the real path; after the operating system locates the first file based on the third path, it performs the read operation or the write operation.

[0030] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke computer instructions to cause the electronic device to execute: the operating system obtains a first string path sent by the first application through the first system call; the operating system converts the first string into a filename structure, the filename structure including a first symbol pointer and a first field; during the process of the operating system converting the first string into a filename structure, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application; the operating system stores the third path at the physical address pointed to by the first symbol pointer, and the operating system stores the second path in the first field.

[0031] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: the first file is a symbolic link file, the content of the first file includes a fourth path, the fourth path being used to indicate the second file; the operating system parses the first file to obtain the fourth path; the operating system determines a fifth path based on the fourth path and the virtual directory corresponding to the first application, the fifth path being used to locate the second file.

[0032] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are specifically configured to invoke the computer instructions to cause the electronic device to perform: the operating system requests a first storage resource for storing a fourth path; the operating system releases the storage resource occupied by the fifth path.

[0033] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to perform: after the operating system determines that the user identifier has switched from a first user identifier to a second user identifier, it switches the current working directory to the working directory corresponding to the second user identifier; after the operating system determines that the application identifier has switched from a first application identifier to a second application identifier, it switches the current working directory to the working directory corresponding to the second application identifier.

[0034] In conjunction with some embodiments of the second aspect, in some embodiments, the one or more processors are further configured to invoke the computer instructions to cause the electronic device to execute: the operating system receives a sixth path sent by the first application; after the operating system determines that the sixth path satisfies the second condition, the operating system inserts a virtual directory corresponding to the first application into the sixth path to obtain a seventh path; before storing the seventh path, the operating system determines that after the seventh path is inserted into the virtual directory corresponding to the first application, the operating system restores the seventh path to the sixth path and stores the sixth path; when a third application uses the sixth path through a third system call, the operating system reads the sixth path and inserts a virtual directory corresponding to the third application into the sixth path to obtain a seventh path; the operating system executes the operation corresponding to the third system call based on the seventh path.

[0035] Thirdly, embodiments of this application provide a chip system applied to an electronic device. The chip system includes one or more processors, which are used to invoke computer instructions to cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0036] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0037] 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 the method described in the first aspect and any possible implementation thereof.

[0038] It is understood that the electronic device provided in the second aspect, the chip system provided in the third aspect, the computer program product provided in the fourth aspect, and the computer storage medium provided in the fifth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0039] Figure 1A , Figure 1B This is an exemplary schematic diagram illustrating the read / write permissions of external storage media for different applications provided in the embodiments of this application.

[0040] Figure 2A , Figure 2B , Figure 2C An exemplary schematic diagram of the file view after implementing the virtual directory creation method in the electronic device provided in the embodiments of this application.

[0041] Figure 3 This is an exemplary schematic diagram illustrating the effect of the virtual directory creation method provided in the embodiments of this application.

[0042] Figure 4 This is an exemplary schematic diagram of the method flow for establishing a virtual directory provided in an embodiment of this application.

[0043] Figure 5 This is an exemplary schematic diagram of a reused filename structure provided in an embodiment of this application.

[0044] Figure 6 This is an exemplary schematic diagram illustrating the determination of the access path passed by the user layer through system calls after inserting a hook function in the getname_flags() function, as provided in an embodiment of this application.

[0045] Figure 7 This is an exemplary schematic diagram of the symbolic link file processing flow provided in the embodiments of this application.

[0046] Figure 8 This is an exemplary schematic diagram illustrating the switching of working directories provided in an embodiment of this application.

[0047] Figure 9A , Figure 9B This application provides an example diagram illustrating the process of saving and then reading the access path in an embodiment.

[0048] Figure 10A This is an exemplary schematic diagram of a file view of an application on an electronic device in a distributed scenario provided in an embodiment of this application.

[0049] Figure 10B This is another exemplary schematic diagram of a file view of an application on an electronic device in a distributed scenario provided in the embodiments of this application.

[0050] Figure 10C , Figure 10D This is an exemplary schematic diagram of the file view of the operating system on the electronic device 1 provided in this application embodiment.

[0051] Figure 11 This is an exemplary schematic diagram of the electronic device hardware architecture provided in the embodiments of this application.

[0052] Figure 12A , Figure 12B This is an exemplary schematic diagram of the electronic device software architecture provided in the embodiments of this application. Detailed Implementation

[0053] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0054] 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.

[0055] 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.

[0056] When an electronic device first runs an application, or during the application's execution, it may request permissions from the user, such as read / write permissions on external storage. For example, in the Android operating system, application developers can use commands such as "<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" / > "To grant an application permission to read data from external storage media, similarly, application developers can use commands such as..."<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" / > "Request permission for the application to write data on external storage media."

[0057] When multiple applications are configured with read / write permissions on external storage media, the data of different applications will be exposed to each other, which can lead to security risks such as data leakage and malicious attacks.

[0058] Figure 1A , Figure 1B This is an exemplary schematic diagram illustrating the read / write permissions of external storage media for different applications provided in embodiments of this application.

[0059] like Figure 1A As shown, the data security storage card, USB flash drive, mobile hard drive, and other electronic devices that establish a telecommunications connection with electronic device 1 can all be external storage media in the embodiments of this application.

[0060] The applications on electronic device 1 include: Application 1, Application 2, Map, Navigation, Calendar, Gallery, Call, etc. Different applications can be configured with different external storage media read / write permissions. For example, Application 1 may have read / write permissions allowed, Application 2 may have read / write permissions allowed, Call may have read / write permissions not allowed, and Gallery may have read / write permissions allowed.

[0061] like Figure 1B As shown, since both application 1 and application 2 have read and write permissions on their external storage media, application 1 can modify the data stored by application 2 on the external storage media, and application 2 can also modify the data stored by application 1 on the external storage media.

[0062] Clearly, in this situation, the data from different applications is not isolated and can be modified by each other, making it impossible to guarantee the security of the application data.

[0063] Similarly, in the Android operating system, if different users are configured with read / write permissions for external storage, any user can modify data stored by other users on external storage, potentially leading to data leakage or tampering. Users can be system accounts logged into on electronic devices, such as… account, Accounts, etc., are not specified here. Users are used to distinguish different accounts logging into the operating system.

[0064] In summary, when different applications and / or users configure the same access permissions for storage media (external or internal storage), the data of different applications and / or users cannot be isolated, which leads to security risks to the data of applications and / or users.

[0065] To achieve isolation of different application and / or user data, embodiments of this application provide a method for establishing a virtual directory, which stores the data of different applications and / or users in different virtual directories. This virtual directory makes the data of applications and / or users invisible to other applications or other users, thereby avoiding the risk of leakage or tampering of application and / or user data and protecting the data of applications and / or users.

[0066] The following is an exemplary description of the virtual directory creation method provided in the embodiments of this application.

[0067] First, the virtual directory creation method provided in this application creates different virtual directories for different applications and / or users, allowing each application and / or user to store their respective data in their respective virtual directories. For the application and / or user, since the paths to the data of other applications and / or users are invisible to the application and / or user, they cannot read / write the data of other applications and / or users.

[0068] Secondly, the virtual directory creation method provided in this application embodiment, since the application and / or user do not know the access paths of other applications and / or users' files, different applications and / or users cannot obtain the access paths of data in different areas on the storage medium, thus equivalently realizing the access permissions of different applications and / or users to different areas.

[0069] The following example uses an external storage medium to illustrate the file view after an electronic device implements a virtual directory creation method. In this embodiment, the file view is a view representing the file hierarchy that is visible to applications and / or users.

[0070] Figure 2A , Figure 2B , Figure 2C An exemplary schematic diagram of the file view after implementing the virtual directory creation method in the electronic device provided in the embodiments of this application.

[0071] like Figure 2A As shown, after implementing the virtual directory creation method provided in this application embodiment, the operating system's file view may include: the / SDcard directory, which includes virtual directory 1 and virtual directory 2. Virtual directory 1 includes N files such as file 11, file 12, ..., file 1N, and virtual directory 2 includes M files such as file 21, file 22, ..., file 2M. However, from the perspective of application 1, application 1's file view includes: the / SDcard directory, which includes N files from file 11 to file 1N; while from the perspective of application 2, application 2's file view includes: the / SDcard directory, which includes M files from file 21 to file 2M.

[0072] The application's file view displays the files that the application can access. Access includes reading, writing, and executing, or any one or more of these.

[0073] Combination Figure 2AAs shown, it is clear that from the perspective of application 1, the / SDcard directory only contains application 1's own data, and there is no data from other applications. Therefore, it is not possible to read / write or modify the data of other applications, thus protecting the data security of application 2.

[0074] like Figure 2B As shown, with Figure 2A The difference is that after implementing the virtual directory creation method provided in this application embodiment, the operating system's file view includes: the / SDcard directory, the / SDcard directory includes directory 1 and other files, directory 1 includes application 1 directory and application 2 directory, application 1 directory includes N files such as file 11, file 12, ..., file 1N, and virtual directory 2 includes application 2 directory including M files such as file 21, file 22, ..., file 2M.

[0075] Combination Figure 2A , Figure 2B As shown in the embodiments of this application, the virtual directory creation method can have one or more layers of file structure. Furthermore, virtual directories can be created only for a portion of the files in the application's files, such as... Figure 2C As shown.

[0076] like Figure 2C As shown, after implementing the virtual directory creation method provided in this application embodiment, the operating system's file view includes: the / SDcard directory, which includes directory 1, directory 2, and files 16, 17, ..., 1N, 26, 27, ..., 2M.

[0077] Directory 1 includes files 11, 12, ..., 15, and directory 2 includes files 21, ..., 25. Directory 1 and directory 2 are virtual directories in this embodiment of the application. Directory 1 is a virtual directory created by the operating system for application 1; directory 2 is a virtual directory created by the operating system for application 2. That is, files in directory 1 are visible to application 1, and files in directory 2 are visible to application 2.

[0078] From the perspective of application 1, the file view of application 1 includes: the / SDcard directory, which contains files 11, 12, 13, 14, 15, ..., 1N, and files 26, 27, ..., 2M. Correspondingly, from the perspective of application 2, the file view of application 2 includes: the / SDcard directory, which contains files 16, 17, ..., 1N, and files 21, 22, ..., 2M.

[0079] Since the files visible to application 1 do not include files 21, 22, ..., 25, application 1 cannot read / write files 21, 22, ..., 25, thus protecting the data security of application 2. Furthermore, since the files visible to application 1 include files 26, 27, ..., 2M, while protecting the data security of application 2, file sharing is also supported, achieving any level of data isolation.

[0080] contrast Figure 2C and Figure 2A Obviously, since virtual directories can be created anywhere in the file directory structure, they can protect the data security of different applications while also enabling data sharing between different applications, thus achieving any degree of data isolation.

[0081] Similarly, the same approach can be achieved for data from different users. Figure 2A , Figure 2B , Figure 2C The virtual directory shown protects the data security of different users.

[0082] Figure 3 This is an exemplary schematic diagram illustrating the effect of the virtual directory creation method provided in the embodiments of this application.

[0083] like Figure 3 As shown, the user layer includes application 1 and application 2. Users can also include applications such as maps, calendars, gallery, navigation, and calling.

[0084] Part of the files of application 1 are located in area 1 of the storage medium, another part of the files of application 1 and part of the files of application 2 are located in area 2 of the storage medium, and part of the files of application 2 are located in area 3 of the storage medium.

[0085] After implementing the data protection method provided in the embodiments of this application, the electronic device establishes such Figure 2C After the virtual directory shown, files 11, 12, ..., 15 can be in region 1; files 16, 17, ..., 1N, 26, 27, ..., 2M can be in region 2; and files 21, 22, ..., 25 can be in region 3. Region 1 and / or region 2 and / or region 3 can be a contiguous range of physical addresses or non-contiguous physical addresses.

[0086] For application 1, files 11, 12, ..., 1N, 26, 27, ..., 2M are visible. Unless otherwise configured to disallow application 1 from having read / write permissions, application 1 can read / write these files, but cannot read / write files 21, 22, ..., 25. Similarly, for application 2, application 2 cannot read / write files 11, 12, ..., 15.

[0087] That is, such as Figure 3 As shown, files in regions 1 and 2 are visible to application 1, while files in region 3 are not visible to application 1; files in region 1 are not visible to application 2, while files in regions 2 and 3 are visible to application 2.

[0088] After exemplarily describing the effects achievable by the virtual directory creation method provided in the embodiments of this application, the method flow of the virtual directory creation method is described exemplarily.

[0089] First, in the virtual directory creation method provided in this application embodiment, the operating system determines whether the application and / or user meet a first condition and whether the access path meets a second condition. When both the first and second conditions are met, a virtual directory corresponding to the application and / or user is inserted into the access path, thereby enabling the application and / or user to obtain their own data.

[0090] Secondly, as I / O read and write is one of the basic functions of the operating system, in order to reduce the impact of the virtual directory creation method provided in this application embodiment on the performance of the operating system, the virtual directory creation method provided in this application embodiment adds hook functions in appropriate locations in the virtual file system (VFS), thereby reducing the modification to the operating system and minimizing the impact on the performance of the operating system.

[0091] Furthermore, to further reduce the impact of the virtual directory creation method provided in this application embodiment on the operating system's performance, the virtual directory creation method provided in this application embodiment reuses existing filename structures in the operating system, such as the filename structure in the Linux operating system, to store the access paths of files sent by user-level applications and / or users through system calls, as well as the modified file paths inserted into the virtual directory. The reuse of the filename structure is not perceived by other modules on the operating system, does not affect the normal operation of other modules, and does not require adaptation from other modules, further reducing the impact of the virtual directory creation method on the operating system's performance.

[0092] Finally, considering the potential virtual directory escape caused by user switching, the virtual directory creation method provided in this application embodiment can promptly switch the virtual directory after a user switch to protect data security. Virtual directory escape refers to a situation where, after a user switch, the current working directory remains in another user's virtual directory, exposing other users' data to the current user.

[0093] The following is combined Figure 4 The content shown illustrates, by way of example, the method flow of the virtual directory creation method provided in the embodiments of this application.

[0094] Figure 4 This is an exemplary schematic diagram of the method flow for establishing a virtual directory provided in an embodiment of this application.

[0095] like Figure 4 As shown, the virtual directory creation method provided in this application includes:

[0096] S401: When user-level applications and / or users perform operations such as opening files through system calls, the operating system obtains the access path of the file.

[0097] User-level applications and / or users need to perform operations such as opening files through system calls to obtain the file descriptor of the file, and then perform read and / or write operations on the file based on the file descriptor.

[0098] The system call can be anything from `open()` to `openat()`, and is not limited here. When user-level applications and / or users perform operations such as opening files through system calls, they need to pass a string-formatted path to the operating system. The operating system obtains the access path of the file based on the system call, and then the kernel-level operating system executes the specific operation, returning the result, such as the file descriptor, to the user-level application and / or user.

[0099] In this embodiment of the application, the path in system call string format obtained by the user-layer application and / or user is referred to as the access path. That is, the access path is the path recorded by the application and / or user and passed to the operating system through a system call.

[0100] In this embodiment of the application, when the access path input by the user space contains all the information needed to determine the location of the file, the access path is called a direct path. In this embodiment of the application, when the access path input by the user space does not contain all the information needed to determine the location of the file, the access path is called an indirect path.

[0101] The operating system can determine whether the string path received from the system call is a direct or indirect path based on whether a file descriptor is received. If the operating system does not receive a file descriptor (fd, filedescriptor), the string path is a direct path; if the operating system receives a file descriptor, the string path is an indirect path. If the access path is an indirect path, the operating system also needs to combine the file descriptor and string path passed in by the user and / or application at the user level to determine the file's location. That is, the operating system needs to combine the access path and the file descriptor to determine the file's direct path.

[0102] It is worth noting that the operating system can determine whether the access path is a direct path or an indirect path during the execution of step S401, or it can choose not to determine whether the access path is a direct path or an indirect path during the execution of step S401.

[0103] S402: The operating system determines whether the application and / or user meet the first condition.

[0104] After receiving a request such as an open file request initiated by an application and / or user through a system call, the operating system can determine whether the application and / or user meet the first condition. If the first condition is met, step S404 is executed; if the first condition is not met, step S403 is executed.

[0105] The first condition can be one or more condition judgments. For example, the first condition may include judging whether the application belongs to a preset application, or judging whether the user belongs to a preset user; or, for example, the first condition may include judging whether the application belongs to a preset application group, or judging whether the user belongs to a preset user group.

[0106] It is worth noting that when the first condition is a combination of multiple conditions, if any one of the first conditions is true, then the first condition is true.

[0107] It is worth noting that the application and / or user did not enable the virtual directory mechanism when the first condition was not met.

[0108] S403: After determining the direct path, the operating system locates the file based on the direct path and performs operations such as opening the file.

[0109] The operating system can determine the direct path based on the access path, and then locate the file. When the application and / or user has not enabled the virtual directory mechanism, this direct path is also the real path.

[0110] When a user-level application and / or user performs a file open operation through a system call, after step S304, the file descriptor or other parameters will be returned to the user-level application and / or user, so that the user-level application and / or user can perform read or write operations on the file through the file descriptor.

[0111] Alternatively, when user-level applications and / or users perform file read or write operations via system calls, the direct path is determined based on the access path and file descriptor, and then the file is located to perform the file read or write operation.

[0112] Optionally, in some embodiments of this application, when the access path is a direct path, the operating system can directly determine the directory entry of the file through the kernel's current structure. For example, when the format of the direct path starts with " / ", such as " / 1 / file1", the directory entry of the file can be determined as " / " based on the process root directory, and then the actual path of the file can be determined as " / 1 / file1".

[0113] Optionally, in some embodiments of this application, when the format of the direct path does not start with " / ", such as "file1", the actual path of the file can be determined based on the current working directory, where the current working directory is " / SDcard / 1 / ", and then the actual path is determined to be " / SDcard / 1 / file1".

[0114] Optionally, in some embodiments of this application, when the access path is an indirect path, the direct path of the file can be determined by the file descriptor and the access path passed by the user layer, thereby determining the actual path of the file. For example, if the access path is "1 / file1" and the directory corresponding to the file descriptor is " / SDcard", then the actual path of the file is " / SDcard / 1 / file1".

[0115] After VFS performs security checks, flag parsing, path tracing, and other operations, kernel structures such as directory entries and index entries are passed to lower-level file systems such as EXT4, where actual file opening, reading, and writing operations are then performed.

[0116] S404: The operating system modifies the access path to the actual path and performs operations such as opening files.

[0117] If step S402 determines that the file's access path is not its location from the operating system's perspective, the actual path needs to be obtained by modifying the access path. Here, the actual path is the file's location from the operating system's perspective.

[0118] Then, the operating system can determine the kernel structure such as the directory entry and inode of the file based on the actual path of the file. After VFS performs security checks, flag resolution, path tracing and other operations, the kernel structure such as the directory entry and inode will be passed to the lower-level file system such as EXT4, and then the actual file opening, reading and writing operations will be performed.

[0119] For example, in the above text Figure 2A Application 1 can pass the access path to the operating system as " / SDcard / file1". Upon receiving the access path, the operating system modifies it to the real path " / SDcard / virtual directory1 / file1". The operating system can determine the correspondence between the virtual directory and the application. For example, if application 1's virtual directory is "virtual directory1", then the virtual directory can be inserted into the access path to obtain the file's real path.

[0120] In this context, one application or one user may correspond to a single virtual directory, or multiple applications or multiple users may correspond to the same virtual directory.

[0121] Optionally, in some embodiments of this application, when the first condition in step S402 is to determine whether a user belongs to a preset user group or whether an application belongs to a preset application group, one application or one user can correspond to a single virtual directory. When the first condition in step S402 is to determine whether a user belongs to a preset user group or whether an application belongs to a preset application group, multiple applications or multiple users can correspond to the same virtual directory.

[0122] For example, if user 1 and user 2 pass the access path " / SDcard / file1" through a system call, and the virtual directory corresponding to user 1 and user 2 is "user group 1", then in this case, the actual path corresponding to the access path is " / SDcard / user group 1 / file1". Similarly, if user 3 and user 4 pass the access path " / SDcard / file1" through a system call, and the virtual directory corresponding to user 3 and user 4 is "user group 2", then in this case, the actual path corresponding to the access path is " / SDcard / user group 2 / file1".

[0123] Similarly, for example, if application 1 and application 2 pass the access path " / SDcard / file1" through a system call, and the virtual directory corresponding to application 1 and application 2 is "application group 1", then in this case, the actual path corresponding to the access path is " / SDcard / application group 1 / file1". If application 3 and application 4 pass the access path " / SDcard / file1" through a system call, and the virtual directory corresponding to application 3 and application 4 is "application group 2", then in this case, the actual path corresponding to the access path is " / SDcard / application group 2 / file1".

[0124] It is worth noting that there are many ways to determine the real path in the embodiments of this application, and no limitation is made here. For example, the real path can be determined by inserting a virtual directory corresponding to the application and / or user into the access path; or, for example, the real path can be obtained by directly modifying the access path, wherein the modification method can correspond to the application and / or user, etc.

[0125] The following describes two exemplary methods for determining the real path, referred to as Method 1 and Method 2.

[0126] (1) Method 1 for determining the real path includes: steps S4041, S4042, S4043, S4044, S4045, and S4046.

[0127] Step S4041: Determine whether the access path is a direct path or an indirect path.

[0128] The operating system can first determine whether the access path received from the user-level application and / or user is a direct path or an indirect path. If the access path is determined to be a direct path, step S4042 can be executed; if the access path is determined to be an indirect path, step S4043 can be executed.

[0129] It is worth noting that when user-level applications and / or users perform file open operations via system calls, the access path is a direct path; when user-level applications and / or users perform file read or write operations via system calls, the access path is an indirect path.

[0130] S4042: Determine if the access path satisfies the second condition.

[0131] The operating system determines whether the direct path meets the second condition. If the second condition is not met, step S405 is executed; if the second condition is met, step S4043 is executed.

[0132] If the second condition is not met, it means that the file accessed by the application and / or user is a file outside the virtual directory.

[0133] The second condition indicates that the file accessed by the application and / or user is a file within a virtual directory.

[0134] First, the access path is completed based on the process root directory or the current working directory. Then, it is determined whether the completed access path satisfies the second condition. The second condition can be one or more conditions. For example, the second condition may include whether the file corresponding to the access path is in a virtual directory; or it may include whether the file corresponding to the access path is on external storage media.

[0135] For example, if the access path is " / 1 / file1", the completed access path is " / SDcard / 1 / file1". Since the completed access path is on external storage media, " / 1 / file1" satisfies the second condition.

[0136] It is worth noting that when the second condition is a combination of multiple conditions, if any one of the conditions is true, then the second condition is true.

[0137] S4043: Determine the real path based on the access path and virtual directory.

[0138] After the operating system determines that the access path is a direct path, it can determine the virtual directory corresponding to the application and / or user based on the application and / or user using the system call, and then determine the real path based on the virtual directory and the access path.

[0139] The real path can be determined by first completing the access path based on the process root directory or the current working directory, and then inserting the virtual directory into the completed access path to obtain the real path.

[0140] For example, if the access path is " / 1 / file1", the completed access path is " / SDcard / 1 / file1", and the actual path is " / SDcard / APP1 / 1 / file1". Here, "APP1" can be a virtual directory.

[0141] Then proceed to step S405.

[0142] S4044: Determine the direct path based on the file descriptor and access path.

[0143] For example, if the access path is "1 / file1" and the directory corresponding to the file descriptor is " / SDcard", then the direct path is " / SDcard / 1 / file1".

[0144] S4045: Determine if the direct path satisfies the second condition.

[0145] The operating system determines whether the direct path meets the second condition. If the second condition is not met, step S405 is executed; if the second condition is met, step S4046 is executed.

[0146] S4046: Determine the real path based on the direct path and virtual directory.

[0147] The operating system can determine the real path based on the direct path and the virtual directory. For example, a virtual directory can be inserted into the direct path to obtain the real path.

[0148] For example, if the direct path is " / SDcard / 1 / file1" and the virtual directory is "APP1", then the real path is " / SDcard / APP1 / 1 / file1". Then proceed to step S405.

[0149] (2) Method 2 for determining the real path includes: steps S4042, S4043, S4047, S4048, S4045, and S4046. The contents of steps S4043, S4045, and S4046 can be referred to the text description in (1) Method 1 for determining the real path, and will not be repeated here.

[0150] S4042: Determine if the access path satisfies the second condition.

[0151] If the access path does not meet the second condition, proceed to step S4047; if the access path meets the second condition, proceed to step S4043.

[0152] Combining steps S4043 and S4042, it can be seen that after receiving the access path sent by the user-level application and / or user through system calls, it does not determine whether the access path is a direct path or an indirect path, and directly treats the access path as a direct path for processing.

[0153] If the function for resolving file descriptors is entered during the subsequent step S4047, it indicates that the access path is an indirect path, and the path processing performed in step S4043 is incorrect. The modified access path needs to be restored to the access path sent by the user-level application and / or the user through a system call. Conversely, if the function for resolving file descriptors is not entered, it indicates that the access path is indeed a direct path, and the path processing performed in step S4043 is correct.

[0154] Steps S4042 and S4043 can occur during the operating system's process of parsing the string path.

[0155] S4047: Should we enter the function used to resolve file descriptors?

[0156] Does it require entering the function used to resolve file descriptors? If yes, proceed to step S4048; otherwise, proceed to step S405.

[0157] If the function that resolves file descriptors is entered, it indicates that the access path is an indirect path. In this case, the processing of the access path in step S4043 needs to be restored, and then the direct path needs to be determined based on the file descriptor and the access path before the real path can be determined. If the function that resolves file descriptors is not entered, it means that the processing of the path in step S4043 was correct and no further modification is needed.

[0158] The operating system parses the file descriptor only after parsing the string path, and then it can determine whether the access path passed by the user layer is a direct path or an indirect path.

[0159] S4048: Restore the real path to the access path, and determine the direct path based on the file descriptor and the access path.

[0160] Since the access path is an indirect path, the modification performed on the access path in step S4043 was incorrect, and the modified access path needs to be restored to the original access path. Then, the direct path is determined based on the access path and the file descriptor.

[0161] Comparing Method 1 and Method 2 for determining the real path in the above embodiments, it can be seen that Method 1 requires modification to the logic of VFS path resolution and file descriptor resolution, resulting in significant kernel changes. To reduce the kernel modifications required for determining the real path, this application provides Method 2 for determining the real path.

[0162] In method 2 for determining the real path, optionally, in some embodiments of this application, a first hook function is added at a suitable location in the VFS layer, and the access path is modified to the real path in the first hook function. The first hook function can be used to execute steps S4042 and S4043.

[0163] Furthermore, optionally, in some embodiments of this application, a first hook function can be inserted into the getname_flags() function provided by VFS to reduce the impact on kernel performance. The getname_flags() function is used to convert the access path passed from the user layer into a filename structure in kernel space.

[0164] It's worth noting that after inserting the first hook function in the `getname_flags()` function, the access path passed by the user layer will be modified regardless of whether it's a direct or indirect path. Clearly, if the access path is a direct path, the first hook function inserted in `getname_flags()` can modify it to the actual path; conversely, if the access path is an indirect path, the first hook function inserted in `getname_flags()` cannot modify it to the actual path. Therefore, in step S4048, the modified access path needs to be restored to its original state.

[0165] Optionally, in some embodiments of this application, the actual path and access path are stored by reusing the kernel's filename structure. For example, the access path can be stored in the iname field of the filename structure, and the actual path can be stored in the space pointed to by the name character pointer. If the name character pointer points to the iname field, it means that the access path has not changed; if iname[0] is 0, it means that the operating system has rearranged the filename structure because the access path is too long; if iname[0] is 1, it means that the access path has been modified to the actual path, the name character pointer points to the actual path, and the path before modification is stored from iname[1] to the first / 0 character position.

[0166] In this embodiment of the application, the first symbol pointer can be a name symbol pointer; the first field can be an iname field.

[0167] Figure 5 This is an exemplary schematic diagram of a reused filename structure provided in an embodiment of this application.

[0168] like Figure 5 As shown, the filename structure includes a name pointer and an iname field. The iname field stores the access path, and the space pointed to by the name pointer stores the actual path. iname[0] is a flag bit, which can take the value 0 or 1.

[0169] Understandably, since the filename structure stores the access path and the modified access path, when step S4048 is executed, the filename structure provides the data basis for the operating system to restore the modified access path to the path before the modification.

[0170] Optionally, in some embodiments of this application, the impact on kernel performance is reduced by inserting a second hook function into the path_init() function. The path_init() function is used to resolve file descriptors. When the second hook function is triggered, it indicates that the operating system enters the function used to resolve file descriptors, i.e., triggering step S4047. The second hook function is used to execute steps S4045 and S4048.

[0171] For example, if the access path of user-level application 1 is "1 / file1", then before the operating system resolves the file descriptor, the access path will be modified to "1 / APP1 / file1" by the first hook function inserted in getname_flags(). If the directory corresponding to the file descriptor resolved by the kernel is " / SDcard", then the direct path determined by the operating system based on the file descriptor and the access path is " / SDcard / 1 / APP1 / file1". It is meaningless to determine whether the path " / SDcard / 1 / APP1 / file1" satisfies the second condition, because " / SDcard / 1 / APP1 / file1" is not the path to the file.

[0172] In this scenario, firstly, the modified access path "1 / APP1 / file1" is restored to the access path passed by the user layer through a system call, such as "1 / file1". Then, the file descriptor is parsed to determine the starting directory as " / SDcard" and the direct path as " / SDcard / 1 / file1". Next, it is determined whether the path " / SDcard / 1 / file1" satisfies the second condition. If the second condition is met, the actual path is determined to be " / SDcard / APP1 / 1 / file1".

[0173] Figure 6 This is an exemplary schematic diagram illustrating how, after inserting a second hook function into the path_init() function, the access path passed by the user layer through a system call is determined, as provided in an embodiment of this application.

[0174] like Figure 6 As shown, specifically, it can be divided into the following three situations:

[0175] In the first case: if the name symbol pointer points to the iname field, it means that the path did not change during the access path processing of the first hook function inserted in the getname_flags() function, and the string pointed to by the name symbol pointer is the access path.

[0176] The second scenario: If the name symbol pointer does not point to the iname field, and the first byte of the iname field has a value of 0, it means that the filename structure has been rearranged due to the path being too long, and the string pointed to by the name symbol pointer is still the access path.

[0177] The third case: If the name symbol pointer does not point to the iname field, and the value of the first byte of iname is 1, it means that in the first hook function inserted in the getname_flags() function, the access path is modified in the processing of the access path, and the address of the original user layer application and / or user-passed access path is iname[1], and ends with \0.

[0178] After obtaining and processing the access path, the path may change again. In this case, if the `name` symbolic pointer does not point to the `iname` field, it means that the data storage method of `filename` has not changed; that is, `filename` itself can reside in the physically contiguous space allocated by the memory allocation function, such as the physically contiguous space allocated by the `kzalloc()` function or the `kmalloc()` function. `name` points to the `kmem_cache` type space obtained by the `_getname()` function. In this case, simply release the `kmem_cache` type space originally pointed to by `name` using the `_putname()` function and set the `name` pointer to the new address. Otherwise, it is necessary to release the `filename` structure, reallocate contiguous space to create a new `filename` structure, and assign values ​​to the fields pointed to by the `name` pointer.

[0179] S405: The operating system locates the file based on a defined direct path or physical path and performs operations such as opening the file.

[0180] After resolving the file access path, the VFS layer passes the modified access path to the underlying real file system and performs the corresponding operations, such as opening a file, writing a file, and reading a file.

[0181] S406: Optional, the file is a symbolic link file, and a virtual directory is inserted into the path indicated by the symbolic link file to determine the actual path of the file indicated by the symbolic link file.

[0182] After the operating system determines that the file is a symbolic link file, it executes step S404 on the path indicated by the symbolic link file.

[0183] Symbolic links, also known as soft links, are a special type of file. A symbolic link file is a reference to another directory or file, and its content is a text string stored in the form of an absolute or relative path; that is, a symbolic link file points to a path.

[0184] To minimize modifications to the kernel and reduce the impact on kernel performance, optionally, in some embodiments of this application, a third hook function can be inserted into the get_link() function, and steps S402, S403, and S404 can be executed within the third hook function. The get_link() function is used to resolve symbolic links and can also be called a soft link writing function.

[0185] Optionally, in some embodiments of this application, after inserting a hook function in the get_link() function, the processing steps for symbolic link files are as follows: Figure 7 As shown.

[0186] Figure 7 This is an exemplary schematic diagram of the symbolic link file processing flow provided in the embodiments of this application.

[0187] like Figure 7 As shown, the process for processing symbolic link files includes:

[0188] S701: The operating system resolves symbolic link files in memory.

[0189] The operating system can use the get_link() function to read the path stored in the symbolic link into memory and parse the path according to the corresponding format.

[0190] Optionally, in some embodiments of this application, the `get_link()` function performs a security check and binds to the `get_link` operation corresponding to the underlying real file system of the VFS before reading the path stored in the symbolic link into memory. Furthermore, the function for releasing the memory space of the storage path can be bound to the `nameidata` structure. After the symbolic link file is used up, the callback function for releasing memory is called, releasing the memory, and the parsing process of the symbolic link file ends.

[0191] S702: Determine if the path indicated by the symbolic link file satisfies the second condition.

[0192] The second condition can be referred to in the description of the second condition in step S4042 above, and will not be repeated here.

[0193] If the path indicated by the symbolic link file meets the second condition, proceed to step S704; if the path indicated by the symbolic link file does not meet the second condition, proceed to step S703.

[0194] S703: End

[0195] If the path indicated by the symbolic link does not satisfy the second condition, the operating system can directly locate the file indicated by the symbolic link based on that path. After resolving the path indicated by the symbolic link, the operating system releases the path indicated by the symbolic link stored in memory.

[0196] S704: Use the path indicated by the symbolic link file as the access path, and modify the access path to the actual path.

[0197] If the path indicated by the symbolic link file satisfies the second condition, then the path indicated by the symbolic link file is used as the access path, and the real path is determined based on the access path. The method for determining the real path can be found in the textual description of step S404 above, and will not be repeated here.

[0198] S705: Newly registered functions for releasing memory occupied by the actual path, releasing memory storing the access path, and ending.

[0199] First, similar to step S703, since the access path is not used to locate the file, the access path in memory can be released. Second, after resolving the actual path, the actual path in memory is released.

[0200] Since the length of the actual path and the length of the access path may be different, it is necessary to register a new function to release the memory occupied by the actual path in order to avoid memory leaks.

[0201] Optionally, in some embodiments of this application, the memory used by the access path can be released by calling the memory release callback function of the access path through the do_delayed_call instruction.

[0202] Optionally, in some embodiments of this application, the set_delayed_call instruction can be used to bind the release function corresponding to the current memory allocation method to the path traversal intermediate structure nameidata, and release the real path in memory after parsing the real path.

[0203] Optionally, in some embodiments of this application, the operating system may use previously saved access paths to perform certain operations. In this case, when the user ID / application ID changes, the current working directory also needs to change accordingly, such as... Figure 8 As shown.

[0204] Figure 8 This is an exemplary schematic diagram illustrating the switching of working directories provided in an embodiment of this application.

[0205] like Figure 8 As shown, the methods for changing the working directory include:

[0206] S801: The operating system detected a change in the application ID and / or user ID.

[0207] The operating system can detect changes in the application ID and / or user ID.

[0208] The following example, using a change in user ID, illustrates a method for determining if a user ID has changed.

[0209] Optionally, in some embodiments of this application, in order to reduce modifications to the operating system kernel and minimize the impact on kernel performance, a fourth hook function can be inserted into the setuid() function, and the working directory switching can be performed in the hook function. The fourth hook function can be the task_fix_setuid() function.

[0210] Specifically, after inserting the fourth hook function into the setuid() function, when the user's ID changes, the setuid() function will be called, and the operating system will then know that the user's ID has changed.

[0211] S802: Determine if the current working directory is within a virtual directory.

[0212] Determine whether the current working directory is within a virtual directory. If yes, proceed to step S803; otherwise, proceed to step S804.

[0213] The method for determining whether the working directory is within the virtual directory can be found in the textual description of step S402 above, and will not be repeated here.

[0214] S803: Determine the virtual directory of the application ID and / or user ID after the switch as the second working directory, and switch the current working directory to the second working directory.

[0215] Step S803 can be executed in the hook function task_fix_setuid().

[0216] Specifically, the virtual directory containing the application ID, account ID, and user ID after the switch is determined as the second working directory. If the second working directory exists, the current working directory is switched to the second working directory; if the second working directory does not exist, it is created.

[0217] S804: End

[0218] The above mainly introduced the method of virtual directory creation when the access path is passed to the operating system by the user-level application and / or user through system calls, and the operating system begins to parse the access path. The following mainly introduces the method of virtual directory creation when the operating system receives the access path but does not immediately perform parsing, but stores it and waits for it to be called when needed.

[0219] Optionally, in some embodiments of this application, the access path passed by the user-layer application and / or user is not directly parsed, but is written to the storage medium and saved, waiting to be read and parsed when needed.

[0220] If the first hook function is inserted in the `getname_flags()` function, the access path will be modified and then saved on the storage medium before being stored. Because the modification of the access path is related to the application and / or user that passed the access path via system calls, and the application and / or user subsequently using the access path may not be the same application or user as the one that passed the access path, the modified access path may not point to the correct virtual directory.

[0221] Figure 9A , Figure 9B This application provides an example diagram illustrating the process of saving and then reading the access path in an embodiment.

[0222] like Figure 9A As shown, this application provides a method for saving and then reading the access path, including:

[0223] S9A01: Transmission Path 1

[0224] When application 2 performs file operations such as reading, writing, and creating files through system calls, the operating system obtains the access path of the file. This access path is path 1.

[0225] For example, path 1 is " / SDcard / file22".

[0226] S9A02: Modify path 1 to path 2 based on the virtual directory corresponding to application 2.

[0227] After receiving path 1, the operating system will generate path 2 based on the virtual directory corresponding to application 2 and path 1, because the first hook function is inserted in the getname_flags() function.

[0228] For example, path 2 is " / SDcard / virtual directory 2 / file 22", where "virtual directory 2" is the virtual directory corresponding to application 2.

[0229] S9A03: Restore path 2 to path 1

[0230] Considering that after saving path 2, the application that calls the file corresponding to path 1 again may not be the same application as in step S9A02, it is necessary to restore path 2 to path 1 first. The method for restoring path 2 to path 1 can be referred to the textual description of step S4048 above, and will not be repeated here.

[0231] Step S9A05 can be executed in the fifth hook function, which is inserted into the do_symlinkat() function. The do_symlinkat() function can be a function that writes symbolic links to a file, or it can be called a soft link reading function.

[0232] S9A04: Storage Path 1

[0233] S9A05: Send a request to access the file corresponding to path 1.

[0234] Application 1 can send read requests, write requests, etc. to the operating system to access the file corresponding to path 1.

[0235] S9A06: Modify path 1 to path 3 based on the virtual directory corresponding to application 1.

[0236] After receiving a request from application 1 for the file corresponding to path 1, the operating system reads path 1 from the storage medium and modifies path 1 to obtain path 3 based on the virtual directory corresponding to application 1. Then, the operating system locates the file according to path 3 and performs the corresponding read operations, write operations, and other operations.

[0237] For example, path 3 is " / SDcard / virtual directory 1 / file 22", where "virtual directory 1" is the virtual directory corresponding to application 1.

[0238] Clearly, if path 4 is determined based on path 2 and the virtual directory of application 1, then path 4 might be " / SDcard / virtual directory 1 / virtual directory 2 / file 22", which is not the correct path.

[0239] like Figure 9B As shown, this application provides a method for saving and then reading the access path, including:

[0240] Among them, steps S9B01 and S9A01 are the same, steps S9B02 and S9A02 are the same, steps S9B04 and S9A05 are the same, and steps S9B06 and S9A06 are the same, which will not be repeated here.

[0241] S9B03: Storage Path 2

[0242] S9B05: Restore path 2 to path 1

[0243] Step S9B05 can be executed in the fifth hook function, which is inserted into the do_symlinkat() function, where the do_symlinkat() function can be a function that writes symbolic links to a file.

[0244] Furthermore, the virtual directory creation method provided in this application embodiment can be applied in a scenario with a single electronic device or in a distributed scenario.

[0245] In a distributed scenario, electronic device 1 and electronic device 2 establish a telecommunications connection, such as a Bluetooth connection or a Wi-Fi connection. Furthermore, both electronic device 1 and electronic device 2 have the same application 1 and application 2 running on them.

[0246] Application 1 on electronic device 1 creates file 1 locally, and application 2 on electronic device 1 creates file 2 locally; correspondingly, application 1 on electronic device 2 creates file 3 locally, and application 2 on electronic device 2 creates file 4 locally.

[0247] Figure 10A This is an exemplary schematic diagram of a file view of an application on an electronic device in a distributed scenario provided in an embodiment of this application.

[0248] like Figure 10A As shown, the file view of application 1 or application 2 on electronic device 1 includes:

[0249] Directory 2 under the root directory is a directory provided by the local file system, while directory 1 under the root directory is a directory provided by the distributed file system. Directory 1 contains files for both electronic device 2 and electronic device 1. Directory 1 further includes both local and remote directories. The local directories are identical to directory 2, both containing files 1 and 2. The remote directories contain files 3 and 4.

[0250] like Figure 10A As shown, the file view of application 1 or application 2 on electronic device 2 includes:

[0251] Directory 4 under the root directory is a directory provided by the local file system, and directory 3 under the root directory is a directory provided by the distributed file system. Directory 3 contains files from electronic device 2 and electronic device 1. Directory 3 further includes both local and remote directories. The local directory is the same as directory 4, and both local and directory 4 contain files 3 and 4. The remote directory contains files 1 and 2.

[0252] Obviously, combining Figure 10AThe content shown indicates that the file views of application 1 and application 2 are the same on electronic device 1, and the file views of application 1 and application 2 are the same on electronic device 2.

[0253] Obviously, before implementing the virtual directory creation method provided in this application embodiment, the files of application 2 are visible to application 1, and application 1 can read and modify the files of application 2; similarly, the files of application 1 are visible to application 2, and application 2 can read and modify the files of application 1.

[0254] After electronic devices 1 and 2 execute the virtual directory creation method provided in the embodiments of this application, the file view is as follows: Figure 10B As shown.

[0255] Figure 10B This is another exemplary schematic diagram of a file view of an application on an electronic device in a distributed scenario provided in the embodiments of this application.

[0256] like Figure 10B As shown, the file view of application 1 on electronic device 1 includes:

[0257] Directory 2 under the root directory is a directory provided by the local file system, while directory 1 under the root directory is a directory provided by the distributed file system. Directory 1 includes both local and remote directories. The local directory is the same as directory 2, and both contain file 1. The remote directory contains file 3.

[0258] like Figure 10B As shown, the file view of application 2 on electronic device 1 includes:

[0259] Directory 2 under the root directory is a directory provided by the local file system, while directory 1 under the root directory is a directory provided by the distributed file system. Directory 1 includes both local and remote directories. The local directory is identical to directory 2; both local and directory 2 contain file 2. The remote directory contains file 4.

[0260] like Figure 10B As shown, the file view of application 1 on electronic device 2 includes:

[0261] Directory 2 under the root directory is a directory provided by the local file system, while directory 1 under the root directory is a directory provided by the distributed file system. Directory 1 includes both local and remote directories. The local directory is identical to directory 2, and both local and directory 2 include file 3. The remote directory includes file 1.

[0262] like Figure 10B As shown, the file view of application 2 on electronic device 2 includes:

[0263] Directory 2 under the root directory is a directory provided by the local file system, while directory 1 under the root directory is a directory provided by the distributed file system. Directory 1 includes both a local directory and a remote directory. The local directory is identical to directory 2; both local and directory 2 include file 4, while the remote directory includes file 2.

[0264] Figure 10C , Figure 10D This is an exemplary schematic diagram of the file view of the operating system on the electronic device 1 provided in this application embodiment.

[0265] like Figure 10C As shown, the file view of the operating system on electronic device 1 includes:

[0266] The root directory includes directory 1 and directory 2. Directory 1 includes a local directory and a remote directory. The local directory includes virtual directory 1 and virtual directory 2. Virtual directory 1 under the local directory includes file 1, and virtual directory 2 under the local directory includes file 2. The remote directory includes virtual directory 1 and virtual directory 2. Virtual directory 1 under the remote directory includes file 3, and virtual directory 2 under the remote directory includes file 4. Directory 2 includes virtual directory 1 and virtual directory 2. Virtual directory 1 under directory 2 includes file 1, and virtual directory 2 under directory 2 includes file 2.

[0267] like Figure 10D As shown, the file view of the operating system on electronic device 1 includes:

[0268] The root directory includes virtual directory 1 and virtual directory 2. The virtual directory includes directory 1 and directory 2. Directory 1 includes a local directory and a remote directory. The local directory under directory 1 of virtual directory 1 includes file 1. The remote directory under directory 1 of virtual directory 1 includes file 3. The directory under virtual directory 1 includes file 1. The virtual directory 2 includes directory 1 and directory 2. The directory under virtual directory 2 includes a local directory and a remote directory. The local directory under directory 1 of virtual directory 2 includes file 2. The remote directory under directory 1 of virtual directory 2 includes file 4. The directory under virtual directory 2 includes file 2.

[0269] Virtual directory 1 is the virtual directory corresponding to application 1; virtual directory 2 is the virtual directory corresponding to application 2.

[0270] Since files 2 and 4 are located in virtual directory 2, which corresponds to the virtual directory of application 2, files 2 and 4 are not visible to application 1. Similarly, since files 1 and 3 are located in virtual directory 1, which corresponds to the virtual directory of application 1, files 1 and 3 are not visible to application 2.

[0271] Understandably, in comparison Figure 10C and Figure 10D The content shown indicates that virtual directories can be created at any file level within a path.

[0272] Understandably, in combination Figure 10A , Figure 10B , Figure 10C , Figure 10D As shown, electronic devices can effectively isolate files from different applications and / or different users by executing virtual directory creation methods, thereby ensuring the data security of different applications or different users.

[0273] Finally, the hardware and software architectures of the electronic devices provided in the embodiments of this application are introduced.

[0274] Figure 11 This is an exemplary schematic diagram of the electronic device hardware architecture provided in the embodiments of this application.

[0275] The electronic device can be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as cellular phone, personal digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, wearable device, in-vehicle device, smart home device and / or smart city device. The embodiments of this application do not impose any special restrictions on the specific type of the electronic device.

[0276] 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.

[0277] 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.

[0278] 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.

[0279] The processor 110 may also include a memory for storing instructions and data.

[0280] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0281] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a limitation on the structure of the electronic device. In other embodiments of this application, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0282] The charging management module 140 is used to receive charging input from the charger. The power management module 141 is used to connect the battery 142, and the charging management module 140 is connected to the processor 110.

[0283] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Mobile communication module 150 can provide solutions for wireless communication applications in electronic devices, including 2G / 3G / 4G / 5G. The modem processor can include a modulator and a demodulator.

[0284] The wireless communication module 160 can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLAN) (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.

[0285] Electronic devices utilize a GPU, a display screen 194, and an application processor to achieve display functionality. The GPU is a microprocessor for image processing, connecting the display screen 194 and the application processor. The display screen 194 is used to display images, videos, etc.

[0286] The ISP is used to process data fed back by the camera 193. The camera 193 is used to capture still images or videos. In some embodiments, the electronic device may include one or N cameras 193, where N is a positive integer greater than 1.

[0287] A digital signal processor (DSP) is used to process digital signals, including digital image signals and other digital signals. A video codec is used to compress or decompress digital video. An NPU (Neural Processing Unit) is a neural network (NN) computing processor that, by borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, rapidly processes input information and can continuously learn. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

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

[0289] Random access memory (RAM) 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, generally referred to as DDR5 SDRAM). Non-volatile memory can include disk storage devices and flash memory. Flash memory can be classified according to its operating principle, including NOR FLASH, NAND FLASH, and 3D NAND FLASH; according to the level of its storage cells, including single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), and quad-level cell (QLC); and according to its storage specification, including universal flash storage (UFS) and embedded multimedia card (eMMC). Random access memory (RAM) 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. Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into RAM for direct read and write by the processor 110.

[0290] The external memory interface 120 can be used to connect to external non-volatile memory, thereby expanding the storage capacity of the electronic device. The electronic device can implement audio functions, such as music playback and recording, through an audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0291] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Speaker 170A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. Receiver 170B, also called a "handpiece," is used to convert audio electrical signals into sound signals. Microphone 170C, also called a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. Headphone jack 170D is used to connect wired headphones.

[0292] The pressure sensor 180A senses pressure signals and converts them into electrical signals. The gyroscope sensor 180B determines the motion posture of the electronic device. The barometric pressure sensor 180C measures air pressure. The magnetic sensor 180D includes a Hall effect sensor. The accelerometer sensor 180E detects the magnitude of acceleration in various directions (typically three axes) of the electronic device. The distance sensor 180F measures distance. The proximity sensor 180G may include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. The LED may be an infrared LED. The ambient light sensor 180L senses ambient light intensity. The fingerprint sensor 180H collects fingerprints. The temperature sensor 180J detects temperature. The touch sensor 180K, also known as a "touch device," is used for temperature detection. The bone conduction sensor 180M acquires vibration signals.

[0293] Button 190 includes the power button, volume buttons, etc.

[0294] Motor 191 can generate vibration alerts. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, messages, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card.

[0295] In this embodiment of the application, the second condition in step S4042 may be to determine whether the location pointed to by the access path is in the external storage medium connected to the external storage interface 120.

[0296] In this embodiment of the application, in step S9A04, path 1 is stored in internal memory 121, for example, in non-volatile memory of internal memory.

[0297] Figure 12A , Figure 12B This is an exemplary schematic diagram of the electronic device software architecture provided in the embodiments of this application.

[0298] The software system of an electronic device can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses a Linux system as an example to illustrate the software structure of an electronic device.

[0299] like Figure 12A As shown, a Linux system can include a user layer and a kernel layer. The user layer can also be called user mode or user space, and the kernel layer can also be called kernel mode or kernel space.

[0300] Linux systems can also include system calls, which are the smallest functional unit of the operating system. Linux systems can also include a shell, which can be called a command interpreter and provides a graphical interface for the user.

[0301] The user layer includes applications such as Application 1 and Application 2. These user-layer applications can pass access paths to the kernel-level file system via system calls.

[0302] A file system can include a virtual file system and a real file system. Upon receiving an access path, the virtual file system first uses a direct path resolution module. This module determines the virtual directory based on the application that invoked the system call, and then generates the real path.

[0303] The direct path resolution module can be used to execute step S4042 and step S4043.

[0304] The indirect path resolution module can be used to execute steps S4044, S4045, and S4046 in method 1 for determining the real path.

[0305] Optionally, when the file corresponding to the real path is a symbolic link file, the symbolic link processing module will process the symbolic link file, that is, the symbolic link processing module will modify the path indicated by the symbolic link file.

[0306] The soft link processing module can be used to execute steps S701, S702, S703, S704, and S705.

[0307] Optionally, the path passed in by the user-level application is modified by the direct path resolution module and stored in the storage medium. When other applications call this path stored in the storage medium, the symbolic link restoration module processes the path, restores the path in the storage medium to the access path, and then modifies it to the actual path corresponding to that other application.

[0308] The symbolic link restoration module can be used to execute... Figure 9A or Figure 9B The steps are shown.

[0309] like Figure 12BAs shown, Linux systems can also include a security framework (LSM, Linux Security Module). The LSM includes a direct path resolution module, an indirect path resolution module, a symbolic link handling module, and a symbolic link restoration module. The roles of the direct path resolution module, indirect path resolution module, symbolic link handling module, and symbolic link restoration module can be found in the above text. Figure 12A The description in the text will not be repeated here.

[0310] The direct path resolution module can be triggered by the first hook function, which can be a path resolution function in the virtual file system, such as the getname_flags() function mentioned above. The direct path resolution module is used to execute steps S4042 and S4043.

[0311] The indirect path resolution module can be triggered by a second hook function, which can be located within a file descriptor processing function, such as the path_init() function mentioned above. The indirect path resolution module is used to execute steps S4048, S4045, and S4046 in method 2 for determining the actual path.

[0312] The symbolic link processing module can be triggered by a third hook function, which can be a symbolic link writing function in the virtual file system, such as the get_link() function mentioned above. The symbolic link processing module can be used to execute steps S701, S702, S703, S704, and S705.

[0313] The symbolic link restoration module can be triggered by the fifth hook function, which can be found in the symbolic link writing function in the virtual file system, such as the `do_symlinkat()` function mentioned above. The symbolic link restoration module can be used to execute... Figure 9A or Figure 9B The steps are shown.

[0314] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[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. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of 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 drive), etc.

[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.

Claims

1. A method for creating a virtual directory, applied to electronic devices, characterized in that, include: The first application performs an open operation on the first file through a first system call; The operating system obtains the first path through the first system call. After the operating system determines that the first application meets the first condition, the operating system determines the direct path corresponding to the first path based on the first path and the starting directory. The direct path is used to determine the location of the first file in the file view of the first application. The starting directory is the process root directory or the current working directory. The first condition includes: the first application belongs to a preset application, or the first application belongs to a preset application group, or the user belongs to a preset user, or the user belongs to a preset user group. After the operating system determines that the direct path meets the second condition, the operating system determines the real path based on the direct path and the virtual directory corresponding to the first application. The second condition includes: the file corresponding to the direct path is in the virtual directory, or the file corresponding to the direct path is in the external storage medium. After locating the first file based on the real path, the operating system returns the file descriptor of the first file to the first application.

2. The method according to claim 1, characterized in that, The method further includes: The first application performs read or write operations on the first file through the second system call; After obtaining the second path and the file descriptor through the first system call, the operating system determines that the second path is an indirect path; The operating system determines the direct path based on the file descriptor of the first file and the second path; After the operating system determines that the direct path satisfies the second condition, the operating system determines the real path based on the direct path and the virtual directory corresponding to the first application. After locating the first file based on the real path, the operating system performs the read operation or the write operation.

3. The method according to claim 1, characterized in that, The method further includes: The first application performs read or write operations on the first file through the second system call; After the operating system obtains the second path and the file descriptor through the first system call, and determines that the second path satisfies the second condition, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application. After the operating system determines that the function used to parse the file descriptor should be executed, the operating system restores the third path to the second path, and the operating system determines the direct path based on the file descriptor of the first file and the second path; After the operating system determines that the direct path satisfies the second condition, the operating system determines the real path based on the direct path and the virtual directory corresponding to the first application. After locating the first file based on the real path, the operating system performs the read operation or the write operation.

4. The method according to claim 1, characterized in that, The method further includes: The first application performs read or write operations on the first file through the second system call; After the operating system obtains the second path and the file descriptor through the first system call, and determines that the second path satisfies the second condition, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application. Once the operating system determines that it will not execute the function used to resolve file descriptors, the third path becomes the actual path; After locating the first file based on the third path, the operating system performs the read operation or the write operation.

5. The method according to claim 3 or 4, characterized in that, The method further includes: The operating system obtains the first string path sent by the first application through the first system call, and the operating system converts the first string into a filename structure, the filename structure including a first symbol pointer and a first field; During the process of the operating system converting the first string into a filename structure, the operating system modifies the second path to the third path according to the virtual directory corresponding to the first application; The operating system stores the third path at the physical address pointed to by the first symbol pointer, and the operating system stores the second path in the first field.

6. The method according to any one of claims 1-4, characterized in that, The first file is a symbolic link file, and the content of the first file includes a fourth path, which is used to indicate the second file; The method further includes: the operating system parsing the first file to obtain the fourth path; the operating system determining a fifth path based on the fourth path and the virtual directory corresponding to the first application, the fifth path being used to locate the second file.

7. The method according to claim 6, characterized in that, Before the operating system determines the fifth path based on the fourth path and the virtual directory corresponding to the first application, the method further includes: the operating system requesting first storage resources to store the fourth path; After the operating system determines the fifth path based on the fourth path and the virtual directory corresponding to the first application, the method further includes: the operating system releasing the storage resources occupied by the fifth path.

8. The method according to any one of claims 1-4, characterized in that, The method further includes: After the operating system determines that the user identifier has switched from the first user identifier to the second user identifier, it switches the current working directory to the working directory corresponding to the second user identifier. After the operating system determines that the application identifier has been switched from the first application identifier to the second application identifier, it switches the current working directory to the working directory corresponding to the second application identifier.

9. The method according to any one of claims 1-4, characterized in that, The method further includes: The operating system receives the sixth path sent by the first application. After the operating system determines that the sixth path meets the second condition, the operating system inserts the virtual directory corresponding to the first application into the sixth path to obtain the seventh path. Before storing the seventh path, the operating system determines that after the seventh path is inserted into the virtual directory corresponding to the first application, the operating system restores the seventh path to the sixth path and stores the sixth path. When a third application uses the sixth path through a third system call, the operating system reads the sixth path and inserts the virtual directory corresponding to the third application into the sixth path to obtain a seventh path. The operating system then executes the operation corresponding to the third system call based on the seventh path.

10. An electronic device, characterized in that, The electronic device includes: one or more processors and a memory; 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, and the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 9.

11. A chip system applied to an electronic device, the chip system comprising one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium comprising instructions, characterized in that, 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 to 9.

13. A computer program product comprising computer instructions that, when executed by one or more processors, implement the method as described in any one of claims 1 to 9.

Images