A file access method and apparatus

Abstract

This application provides a file access method and apparatus, relating to the field of communication technology. The method includes: mapping a first file directory in a local file system to a second file directory in the file system of a second device; upon receiving an access request for a target file sent by the second device, if the target file is a file accessible to a target application, then responding to the access request, wherein the target application is an application in the second device requesting access to the target file, the target file is a file in the first file directory, and the access request is a request generated by the target application based on the mapping path of the target file in the second file directory; otherwise, if the target application is a trusted signature program, then responding to the access request. The solution provided by this application can enable file access between devices.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a file access method and apparatus. Background Technology

[0002] With the rapid development of IoT technology, interconnection between various devices is becoming more and more common, data interaction between devices is becoming more and more frequent, and the need for cross-device file access is becoming more and more frequent.

[0003] Therefore, a file access scheme is needed to enable file access between devices. Summary of the Invention

[0004] The purpose of this application is to provide a file access method and apparatus to enable file access between devices. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide a file access method applied to a first device, the method comprising:

[0006] Map the first file directory in the local file system to the second file directory in the file system of the second device;

[0007] Upon receiving an access request for a target file from the second device, if the target file is a file that the target application is allowed to access, then the access request is responded to, wherein the target application is: the application in the second device that requests access to the target file, the target file is a file in the first file directory, and the access request is: a request generated by the target application based on the mapping path of the target file in the second file directory;

[0008] Otherwise, if the target application is a trusted signing program, the access request will be responded to.

[0009] In one embodiment of this application, whether the target application is a trusted signing program is determined by the following method:

[0010] Obtain the signature file of the target application from the second device;

[0011] If the target application is a system program and the signature file contains a system tag, then the target application is determined to be a trusted signature program.

[0012] If the target application is a third-party program and the signature file is valid, the target application is verified based on the signature information and verification information contained in the signature file. If the verification is successful, the target application is determined to be a trusted signature program.

[0013] In one embodiment of this application, whether the target file is a file that the target application is allowed to access is determined by the following method:

[0014] Obtain the process identifier of the target application from the second device;

[0015] Based on the process identifier, determine whether the target file is a file that the target application is allowed to access.

[0016] In one embodiment of this application, responding to the access request includes:

[0017] Obtain the mapping path of the target file in the second file directory;

[0018] If the mapping path is a valid path, then the access request is responded to based on the mapping path;

[0019] If the mapped path is invalid, the original path of the target file in the first file directory is obtained, the mapped path is repaired based on the original path, and the access request is responded to based on the repaired mapped path.

[0020] In one embodiment of this application, responding to the access request includes:

[0021] If there are multiple unanswered requests to access the target file, determine the response order of the access request among the other requests;

[0022] If the order for responding to the access request is not reached, the access thread used to respond to the access request is locked;

[0023] When the order for responding to the access requests is reached, the access thread is unlocked, and the access request is responded to based on the access thread.

[0024] Secondly, embodiments of this application provide a file access device applied to a first device, the device comprising:

[0025] The file directory mapping module is used to map a first file directory in the local file system to a second file directory in the file system of the second device.

[0026] The first access request response module is configured to, upon receiving an access request for a target file sent by the second device, respond to the access request if the target file is a file that the target application is allowed to access; otherwise, trigger the second access request response module. The target application is an application in the second device that requests access to the target file, the target file is a file in the first file directory, and the access request is a request generated by the target application based on the mapping path of the target file in the second file directory.

[0027] The second access request response module is used to respond to the access request if the target application is a trusted signing program.

[0028] In one embodiment of this application, whether the target application is a trusted signing program is determined by the following method:

[0029] Obtain the signature file of the target application from the second device; if the target application is a system program and the signature file contains a system tag, then determine that the target application is a trusted signature program; if the target application is a third-party program and the signature file is valid, then verify the target application according to the signature information and verification information contained in the signature file, and if the verification is successful, determine that the target application is a trusted signature program.

[0030] In one embodiment of this application, whether the target file is a file that the target application is allowed to access is determined by the following method:

[0031] Obtain the process identifier of the target application from the second device; based on the process identifier, determine whether the target file is a file that the target application is allowed to access.

[0032] In one embodiment of this application, responding to the access request includes:

[0033] Obtain the mapping path of the target file in the second file directory; if the mapping path is a valid path, respond to the access request based on the mapping path; if the mapping path is an invalid path, obtain the original path of the target file in the first file directory, repair the mapping path based on the original path, and respond to the access request based on the repaired mapping path.

[0034] In one embodiment of this application, responding to the access request includes:

[0035] If there are multiple unresponsive requests to access the target file, determine the response order of the access requests among the other requests; if the order for responding to the access requests has not been reached, lock the access thread used to respond to the access requests; if the order for responding to the access requests has been reached, unlock the access thread, and respond to the access requests based on the access thread.

[0036] Thirdly, embodiments of this application provide an electronic device, including:

[0037] Memory, used to store computer programs;

[0038] The processor, when executing a program stored in memory, implements the file access method described in the first aspect above.

[0039] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the file access method described in the first aspect.

[0040] Fifthly, embodiments of this application also provide a computer program product containing instructions that, when run on a computer, cause the computer to perform the file access method described in the first aspect.

[0041] As can be seen from the above, when using the solution provided in the embodiments of this application for file access, the first file directory in the local file system is first mapped to the second file directory in the file system of the second device. In this way, the target application in the second device can access the first file directory through the second file directory and determine the target file in the first file directory to be accessed. Then, the second device can send an access request for the target file to the first device. The first device can respond to the access request, so that the target application in the second device can successfully access the target file in the first device, thus realizing cross-device file access.

[0042] Furthermore, after receiving an access request for the target file from the second device, the first device determines whether to respond to the access request based on the access permissions of the target application on the second device. If the target file is a file that the target application is allowed to access, the access request is responded to; otherwise, the application is further verified for a trusted signature program. Only if the signature program is trusted is the access request responded to. Therefore, in responding to the above access requests, multiple authentications are performed on the application on the second device accessing the target file. This ensures that the access request is only responded to if the target application meets the access requirements, thus allowing the target application to access the target file. This helps filter access requests from malicious applications for the target file, thereby preventing malicious applications from stealing and distributing the target file on the first device, and improving the security of files on the first device during cross-device file access.

[0043] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0045] Figure 1 A flowchart illustrating the first file access method provided in this application embodiment;

[0046] Figure 2 A flowchart illustrating the second file access method provided in this application embodiment;

[0047] Figure 3 A flowchart illustrating the third file access method provided in this application embodiment;

[0048] Figure 4 This is a schematic diagram of the structure of a file access device provided in an embodiment of this application;

[0049] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0051] First, the implementing entity of the solution provided in the embodiments of this application will be described.

[0052] The implementation subject of the solution provided in this application embodiment is an electronic device that receives a file access request initiated by the access initiating device and responds based on the access request.

[0053] In this application embodiment, the electronic device that responds can be referred to as the first device, and the access initiating device can be referred to as the second device.

[0054] The file access method provided in the embodiments of this application will be described in detail below.

[0055] See Figure 1 , Figure 1 This is a flowchart illustrating a first file access method provided in an embodiment of this application, applied to a first device. The method includes the following steps S101-S105.

[0056] Step S101: Map the first file directory in the local file system to the second file directory in the file system of the second device.

[0057] The local file system is the software system within the operating system of the first device that is responsible for managing and storing file information.

[0058] The contents of the first file directory in the local file system that is mapped to the file system of the second device can be in the following ways.

[0059] In the first scenario, the first file directory can be any file directory in the local file system.

[0060] In the second scenario, the first file directory can be a pre-defined portion of the file directories in the local file system. For example, the aforementioned pre-defined portion of the file directories could be directories with access permissions set.

[0061] In the third case, the first device can determine the file directory indicated by the first identifier in the local file system as the first file directory based on the first identifier of the file directory to be accessed sent by the second device.

[0062] This situation applies when the second device has previously accessed files in the first device, that is, the second device's file system has a mapping of file directories in the first device's file system. In this case, the second device can record the aforementioned file directories, and during this access, use the aforementioned file directories as the file directories to be accessed, or use a portion of the file directories in the aforementioned file directories as the file directories to be accessed, and then send the first identifier of the file directories to be accessed to the first device.

[0063] The following explains the directory mapping method described above.

[0064] Specifically, the first device can receive a second identifier of the second file directory sent by the second device, and mount the first file directory to the second file directory indicated by the second identifier. In this case, the second file directory can also be referred to as the mount point.

[0065] Of course, before the first device maps the first file directory in the local file system to the second file directory in the file system of the second device, this step also includes essential basic steps such as establishing a communication connection with the second device and initializing the local file system. For details of these steps, please refer to the subsequent embodiments, which will not be described in detail here.

[0066] Step S102: Receive an access request for the target file sent by the second device.

[0067] The target file is a file in the first file directory, and the access request is a request generated by the target application based on the mapping path of the target file in the second file directory.

[0068] The target application mentioned above is the application on the second device that requests access to the target file. It can be an application used to open, play, edit, or perform other operations on the target file. For example, the target application can be a text editing application, an audio playback application, a video playback application, a compressed file viewing application, etc.

[0069] Since the second file directory is a file directory in the file system of the second device, after mapping the first file directory to the second file directory, the target application in the second device can access the first file directory through the second file directory, thereby determining the target file to be accessed in the first file directory, and thus generating an access request for the target file. The path of the target file in the second file directory is the mapped path.

[0070] As can be seen from the above description, the actual path of each file contained in the first file directory corresponds to a mapped path in the second file directory.

[0071] Step S103: Determine whether the target file is a file that the target application is allowed to access. If yes, proceed to step S104; otherwise, proceed to step S105.

[0072] In this step, it is determined whether the target file is a file that the target application is allowed to access; this can also be understood as determining whether the target application has permission to access the target file.

[0073] The following describes the specific methods for determining whether a target file is one that the target application is allowed to access.

[0074] Specifically, the process identifier of the target application can be obtained from the second device, and based on the process identifier, it can be determined whether the target file is a file that the target application is allowed to access.

[0075] The process identifier mentioned above can be the process's UID (User Identification), which can represent the user level of the process creator; or it can be the PID (Process Identification), which can represent information such as the process creation order.

[0076] Of course, the process identifier mentioned above can also be EUID (Effective User Identification), PPID (Parent Process Identification), etc., and this application does not limit it.

[0077] Specifically, based on the different process identifiers mentioned above, the following examples illustrate how to determine whether a target file is a file that the target application is allowed to access, based on the process identifier.

[0078] In one implementation, the process identifier is a UID. In this case, the target file can be determined as a file that the target application is allowed to access based on the user level corresponding to the UID.

[0079] Specifically, it can be determined whether the above UID belongs to the preset user-level UID set corresponding to the target file. If so, the target file is determined to be a file that the target application is allowed to access.

[0080] For example, if the UID set corresponding to target file f1 is {0}, this set is the UID set of the root user (also known as the superuser). This means that when the process creator of the target application is the root user, the target application can access the target file. As another example, if the UID set corresponding to target file f2 is {1, 2, 3, ..., 499}, this set is the UID set of the system user. This means that when the process creator of the target application is the system user, the target application can access the target file.

[0081] In another implementation, the process identifier is a PID. In this case, it can be determined whether the PID is in a preset format. If so, the target file is determined to be a file that the target application is allowed to access.

[0082] The aforementioned preset format can be notified to the second device in advance by the first device. In this way, the second device can assign a PID to the target application according to the aforementioned format. When the second device detects that the PID of the target application is in the preset format, it determines that the target file is a file that the target application is allowed to access.

[0083] This ensures that only target applications created by the second device with corresponding PIDs in a preset format can access the target file. When a malicious application creates a process without authorization on the second device, its corresponding PID may not conform to the preset format. This helps to identify the target file as a file that the malicious application is not allowed to access based on the aforementioned PID.

[0084] It should be noted that the embodiments of this application do not limit the specific content of the above-mentioned preset format. For example, the above-mentioned preset format may be the value range of the first digit of the PID, the parity type of the last digit of the PID, etc.

[0085] In another implementation, the process identifier includes a UID and a PID. In this case, the two implementations described above can be combined. If the UID belongs to the preset user-level UID set corresponding to the target file and / or the PID is in a preset format, the target file is determined to be a file that the target application is allowed to access.

[0086] Since the process identifier of an application can represent information such as the user level of the process creator and the order in which the process was created, it can be used to identify a process. Therefore, using the process identifier of the target application as a basis can accurately and conveniently determine the access permissions of the target application to the target file.

[0087] Step S104: Respond to the access request.

[0088] If the target file is a file that the target application is allowed to access, then the first device can respond to the access request sent by the second device, thereby allowing the target application in the second device to access the target file in the first device.

[0089] Specifically, the following sections explain how to respond to access requests from different perspectives.

[0090] In one scenario, from the perspective of determining the operations that the target application can perform on the target file, the first device, when responding to the aforementioned access request, can also determine the executable operations of the target file, allowing the target application to operate on the target file within the scope of these executable operations. These executable operations can be read from the target file's attribute information, and may include whether reading or writing is permitted.

[0091] In another scenario, to prevent multiple target applications from accessing the target file simultaneously, the first device can determine the response order of each access request relative to other requests. Based on this response order, it can lock or unlock the access thread for each access request, and respond to the access request based on the access thread when the access thread is unlocked. For detailed implementation methods, see [link to implementation details]. Figure 1 The embodiments shown below are not described in detail here.

[0092] In another scenario, depending on whether the target application on the second device can successfully access the target file, the first device can obtain the mapping path of the target file in the second file directory and respond to the access request in different ways based on the validity of the mapping path. Detailed implementation methods will be provided later. Figure 3 Steps S304-S306 in the illustrated embodiment will not be described in detail here.

[0093] Step S105: Determine whether the target application is a trusted signing program. If yes, proceed to step S104.

[0094] A trusted signature program indicates that an application downloaded and installed from a legitimate source and certified by the signature program will not pose a threat to the security of the target file on the first device. Even if the target file is not a file that the target application is allowed to access, the target application can still be allowed to access it if the target application is a trusted signature program.

[0095] Therefore, in this step, if the target file is not a file that the target application is allowed to access, it is determined whether the target application is a trusted signing program. If it is, the access request sent by the second device is responded to, thereby allowing the target application in the second device to access the target file.

[0096] Specifically, the following methods can be used to determine whether a target application is a trusted signing program.

[0097] In one implementation, it can be determined whether the target application is an application in the locally recorded list of trusted signature programs. If it is, the target application is determined to be a trusted signature program; if it is not, the target application is determined to be a trusted signature program.

[0098] In another implementation, the signature file of the target application can be obtained first. Then, depending on whether the target application is a system application, different methods can be used to determine whether the target application is a trusted signing program based on the signature file. Detailed implementation methods will be provided later. Figure 2 Steps S205-S210 in the illustrated embodiment will not be described in detail here.

[0099] As can be seen from the above, when using the solution provided in the embodiments of this application for file access, the first file directory in the local file system is first mapped to the second file directory in the file system of the second device. In this way, the target application in the second device can access the first file directory through the second file directory and determine the target file in the first file directory to be accessed. Then, the second device can send an access request for the target file to the first device. The first device can respond to the access request, so that the target application in the second device can successfully access the target file in the first device, thus realizing cross-device file access.

[0100] Furthermore, after receiving an access request for the target file from the second device, the first device further determines whether to respond to the access request based on the access permissions of the target application on the second device and whether the target application is a trusted signature program. Specifically, if the target file is a file that the target application is allowed to access, the access request is responded to; otherwise, the application is further assessed for its trusted signature program status, and only if it is a trusted signature program is the access request responded to. It is evident that in responding to the above access requests, multiple authentications are performed on the application on the second device accessing the target file, ensuring that the access request is only responded to if the target application meets the access requirements, thus allowing the target application to access the target file. This helps filter access requests from malicious applications for the target file, thereby preventing malicious applications from stealing and distributing the target file on the first device, and improving the security of files on the first device during cross-device file access.

[0101] Furthermore, existing technologies often rely on screen mirroring to achieve cross-device file access. The accessed device plays the file in real time and sends the data stream of the played content to the initiating device. The initiating device then displays the content played on the accessed device locally based on the received data stream. However, the above solutions can only support displaying playable files such as images, audio, and video from the accessed device on the initiating device, and cannot enable the initiating device to access other file formats such as documents and compressed files on the accessed device.

[0102] When using the solution provided in this application embodiment for file access, only the first device and the second device need to have network transmission capabilities, which enables the second device to access various types of files in the first device, thus improving the compatibility of file access.

[0103] The following steps, A and B, will explain the necessary basic steps before performing the aforementioned step S101.

[0104] Step A: Establish a communication connection with the second device.

[0105] Establishing a communication connection with the second device can be initiated by either the first device or the second device.

[0106] For example, the first device can receive a communication connection establishment request sent by the second device, and establish a communication connection with the second device based on the received establishment request.

[0107] Specifically, the first device can establish a communication connection with the second device in the following ways.

[0108] In one implementation, after receiving a communication connection establishment request from a second device, the first device can determine whether the second device is connected to the same trusted network as itself. If so, it can establish a communication connection with the second device.

[0109] This ensures that both the first and second devices are in the same trusted network environment, preventing network attacks during file access and improving security during file access.

[0110] In another implementation, after receiving a communication connection establishment request from the second device, the first device can determine whether the communication connection establishment request is a request sent based on a reliable communication protocol. If so, a communication connection is established with the second device.

[0111] The aforementioned reliable communication protocols can be TCP (Transmission Control Protocol), CAN (Controller Area Network) protocol, etc.

[0112] This ensures that the communication process is stable and reliable, which helps improve the stability of file access.

[0113] In another embodiment, the two embodiments described above can be combined. After receiving a communication connection establishment request sent by the second device, the first device establishes a communication connection with the second device when it determines that the second device is in the same trusted network and that the communication connection establishment request is a request sent based on a reliable communication protocol.

[0114] Step B: Initialize the local file system.

[0115] The local file system is loaded into an available state, allowing the first file directory in the local file system to be mapped to a second file directory in the second device's file system. This step is generally performed before step A above, for example, when the first device is first used. It is not required every time a communication connection is established or every time a file on the first device is accessed.

[0116] Furthermore, step A above is not executed every time a file on the first device is accessed by the second device. As long as the communication connection between the first and second devices is available when the application on the second device requests access to a file on the second device, there is no need to repeat step A above.

[0117] The foregoing mentioned the perspective of whether the target application in the second device can successfully access the target file. Step S104 can have other implementation methods when responding to the access request. The above implementation methods will be explained below through step CE.

[0118] Step C: If there are multiple unresponsive requests to access the target file, determine the response order of the access requests and other requests.

[0119] Specifically, the response order of each access request can be determined in the following ways.

[0120] In one implementation, the response order of each access request can be determined based on the request initiation time of each access request.

[0121] For example, the response order of each access request can be determined according to the order in which the request was initiated, from earliest to latest.

[0122] In another implementation, the response order of each access request can be determined based on the process identifier of the target application in the second device that initiated each access request. Two methods are illustrated below.

[0123] In the first approach, if the process identifier is a UID, the access requests can be sorted in descending order of user level represented by the UID to obtain the response order. Specifically, for access requests with the same user level, they can be sorted according to the request initiation time, as described in the previous implementation method.

[0124] The second approach is to sort the access requests according to the PID values ​​from smallest to largest to obtain the response order, if the process is identified by a PID.

[0125] Step D: If the order of responding to access requests is not met, lock the access thread used to respond to the access requests.

[0126] For each access request, the first device created an access thread to process it.

[0127] If the access thread corresponding to an access request that does not meet the above response order is locked, then the access thread is in a dormant state. That is, the first device will not respond to the access request corresponding to the access thread, and thus the target application in the second device that initiated the access request cannot access the target file.

[0128] Step E: When the order of responding to access requests is reached, unlock the access thread and respond to access requests based on the access thread.

[0129] The access thread corresponding to the access request that meets the above response order is unlocked, the access thread is activated, and the first device can respond to the access request corresponding to the access thread, thereby enabling the target application in the second device that initiated the above access request to access the target file.

[0130] As can be seen from the above, this ensures that each access request is processed in the order of response, which helps prevent responding to multiple access requests at the same time. This avoids problems such as file data corruption caused by multiple target applications accessing the target file at the same time, and improves the stability of the file access process.

[0131] In one embodiment of this application, the first device may also receive file operators of the target file and modification information for the target file sent by the second device, and modify the target file in the local file system based on the received information.

[0132] The file operators mentioned above are used to identify the target file. The modification information mentioned above can be the modified target file or the modifications made to the target file.

[0133] This allows users to remotely modify target files on the first device from the second device, improving the convenience and flexibility of modifying target files on the first device.

[0134] In the foregoing Figure 1 Based on the illustrated embodiment, the signature file of the target application can be obtained first. Then, depending on whether the target application is a system application, different methods are used to determine whether the target application is a trusted signature program based on the signature file. In view of the above, the second file access method provided in this application embodiment...

[0135] See Figure 2 , Figure 2 This is a flowchart illustrating a second file access method provided in an embodiment of this application, applied to a first device. The method includes the following steps S201-S210.

[0136] Step S201: Map the first file directory in the local file system to the second file directory in the file system of the second device.

[0137] Step S202: Receive an access request for the target file sent by the second device.

[0138] Step S203: Determine whether the target file is a file that the target application is allowed to access. If yes, proceed to step S204; otherwise, proceed to step S205.

[0139] Step S204: Respond to the access request.

[0140] Steps S201-S204 described above can be performed as described in the previous section. Figure 1 The embodiments shown are based on steps S101-S104, with the only difference being the different step numbers, which will not be repeated here.

[0141] Step S205: Obtain the signature file of the target application from the second device.

[0142] The signature file is a file containing encrypted authentication information used for trusted authentication of the application.

[0143] Specifically, the first device can receive the signature file carried by the second device when sending the access request, or it can send a request to the second device to obtain the signature file for the target application, and then receive the aforementioned signature file from the second device.

[0144] Step S206: Determine whether the target application is a system application. If yes, proceed to step S207; otherwise, proceed to step S208.

[0145] The aforementioned system program can be a certified application developed internally by the manufacturer of the first device, and its reliability is high. For example, if the first device is a surveillance camera, the aforementioned system program can be an application developed by the surveillance camera manufacturer for reading data stored in the surveillance camera.

[0146] Specifically, the first device may record the application package name of the aforementioned system program. The first device may send a request to the second device to obtain the application package name of the target application. The first device may determine whether the application package name returned by the second device belongs to the application package name recorded in the first device. If yes, the first device may determine that the target application is a system program. If no, the first device may determine that the target application is a third-party program.

[0147] Step S207: Determine whether a system tag exists in the signature file. If yes, proceed to step S204.

[0148] The aforementioned system tags can be understood as tags added by the manufacturer of the first device to the signature file of the system application when developing the system application.

[0149] To prevent the target application from being a counterfeit system application, the first device can further determine whether there is a system tag in the target application's signature file. If so, the target application can be determined to be a genuine system application, that is, a trusted application, and thus respond to the above access request.

[0150] Step S208: Determine if the signature file is valid. If it is, proceed to step S209.

[0151] If the first device determines that the target application is not a system application but a third-party application, the first device can first determine whether the signature file is valid.

[0152] Specifically, the first device can determine whether a signature file is valid by judging whether the content of the signature file is correct, whether the format of the signature file is correct, and whether the signature file is within the validity period.

[0153] If the aforementioned signature file is valid, it means that the signature file can be used to assess whether the target application is a trusted signature program. Therefore, the target application can be further verified based on the signature information and verification information contained in the signature file.

[0154] Step S209: Verify the target application based on the signature information and verification information contained in the signature file.

[0155] The aforementioned signature information may include the digital signature of the target application, and the aforementioned verification information may include the public key for encrypting the digital signature.

[0156] Specifically, the digital signature can be decrypted using the aforementioned public key, and then the decrypted data can be compared with the original digital signature. If they match, the verification of the target application is deemed successful; otherwise, the verification of the target application is deemed unsuccessful.

[0157] Step S210: Determine whether the verification is successful. If yes, proceed to step S204.

[0158] If the verification is successful, it indicates that the target application is a trusted signing program, and step S204 can be executed to respond to the access request from the second device.

[0159] As can be seen from the above, when accessing files using the solution provided in this application, a trusted application determination is performed on the target application. Only when the target application is a trusted application will the access request from the second device be responded to, allowing the target application to access the target file. This prevents untrusted applications from accessing target files on the first device, thus improving the security of target files on the first device during file access.

[0160] In addition, the system application is an application developed internally by the first equipment manufacturer and has been certified, so its credibility is relatively high; in contrast, the third-party application is an application developed by a third-party developer, so its credibility is relatively low. The embodiments of this application can use different methods to determine whether the target application is a system program or a third-party program, so as to more reasonably and effectively determine whether the target application is a trusted signature program based on the characteristics of system programs or third-party programs.

[0161] exist Figure 1 Based on the illustrated embodiment, from the perspective of preventing multiple applications from accessing the target file simultaneously, when responding to access requests, the first device can determine the response order between each access request and other requests, lock or unlock the access thread for each access request based on the aforementioned response order, and respond to the access request based on the access thread when the access is unlocked. In view of the above, this application embodiment provides a third file access method.

[0162] See Figure 3 This is a flowchart illustrating a third file access method provided in this application embodiment, applied to a first device. The method includes the following steps S301-S307.

[0163] Step S301: Map the first file directory in the local file system to the second file directory in the file system of the second device.

[0164] Step S302: Receive an access request for the target file sent by the second device.

[0165] Steps S301 and S302 described above can be performed as described in the preceding paragraph. Figure 1 The embodiments shown are based on steps S101 and S102, with the only difference being the different step numbers, which will not be repeated here.

[0166] Step S303: Determine whether the target file is a file that the target application is allowed to access. If yes, proceed to step S304; otherwise, proceed to step S307.

[0167] In this step, the method for determining whether the target file is a file that the target application is allowed to access is detailed above. Figure 1 Step S103 in the illustrated embodiment will not be described again here.

[0168] Step S304: Obtain the mapping path of the target file in the second file directory.

[0169] Specifically, the first device can receive the aforementioned mapping path carried by the second device when sending an access request, or it can send a request to the second device to obtain the aforementioned mapping path, and then receive the aforementioned mapping path returned by the second device.

[0170] Step S305: If the mapped path is a valid path, respond to the access request based on the mapped path.

[0171] Specifically, you can determine whether a mapping path is a valid path using the following methods.

[0172] In one implementation, it can be determined whether the actual path corresponding to the above-mentioned mapped path in the first file directory of the local file system contains the target file, that is, whether the actual path corresponding to the above-mentioned mapped path can access the target file. If yes, the mapped path is determined to be a valid path; if no, the mapped path is determined to be an invalid path.

[0173] In another implementation, if the above-mentioned mapped path is a valid path format, it can be further determined whether the actual path corresponding to the above-mentioned mapped path can access the target file. If it is, the mapped path is determined to be a valid path; if it is not, the mapped path is determined to be an invalid path.

[0174] If the mapping path is determined to be a valid path, the target application in the second device can access the target file according to the above mapping path. Therefore, an access request can be responded to for the above mapping path so that the target application in the second device can access the target file according to the mapping path.

[0175] Step S306: If the mapped path is invalid, obtain the original path of the target file in the first file directory, repair the mapped path based on the original path, and respond to the access request based on the repaired mapped path.

[0176] The specific method for determining whether a mapping path is a valid path is explained in step S305 above, and will not be repeated here.

[0177] If the above mapping path is invalid, it means that the target file does not exist in the actual path corresponding to the above mapping path.

[0178] For example, if the actual path of the target file in the first device changes, the target file will not exist in the original actual path corresponding to the above-mentioned mapping path; or if the mapping between the second file directory in the first device and the second file directory in the second device is interrupted due to network fluctuations, the target file will also not exist in the original actual path corresponding to the above-mentioned mapping path.

[0179] In this case, the second device cannot access the target file based on the above mapping path. Therefore, the original path of the target file in the first file directory can be obtained, and the mapping path can be repaired based on the original path.

[0180] The following explains how to repair the mapped path based on the original path.

[0181] In one implementation, the file directory where the original path is located can be mapped to the aforementioned second file directory. In this way, the second device can determine the new actual path of the target file based on the mapping path of the target file in the second file directory. The aforementioned new actual path is the original path.

[0182] In another implementation, a mapping relationship can be established only for the above-mentioned mapping path and the original path, and the above-mentioned mapping relationship can be sent to the second device. In this way, the second device can determine the original path of the target file based on the mapping path and the above-mentioned mapping relationship.

[0183] Specifically, after repairing the mapped path based on the original path, the system can respond to the aforementioned access request and send the original path to the second device, enabling the second device to access the target file based on the original path.

[0184] Step S307: Determine whether the target application is a trusted signing program. If yes, proceed to step S304.

[0185] In this step, the method for determining whether the target application is a trusted signing program is detailed above. Figure 2 Steps S205-S210 in the illustrated embodiment will not be repeated here.

[0186] As can be seen from the above, when using the solution provided in the embodiments of this application to access files, after determining that the target application located in the second device has access permissions to the target file in the first device, it can also determine whether the mapping path of the target file in the second file directory is valid. In this way, if the above mapping path is invalid, the mapping path can be repaired based on the original path of the target file in the first file directory, so that the target application can successfully access the target file. This is beneficial to improving the success rate of the target application accessing the target file when it has access permissions, and improving the efficiency of file access.

[0187] Corresponding to the above-described file access method, this embodiment of the invention provides a file access device.

[0188] See Figure 4 , Figure 4 This is a schematic diagram of a file access device provided in an embodiment of this application. The device includes the following modules 401-403.

[0189] File directory mapping module 401 is used to map a first file directory in the local file system to a second file directory in the file system of the second device.

[0190] The first access request response module 402 is configured to, upon receiving an access request for a target file sent by the second device, respond to the access request if the target file is a file that the target application is allowed to access; otherwise, trigger the second access request response module. The target application is an application in the second device that requests access to the target file, the target file is a file in the first file directory, and the access request is a request generated by the target application based on the mapping path of the target file in the second file directory.

[0191] The second access request response module 403 is used to respond to the access request if the target application is a trusted signing program.

[0192] As can be seen from the above, when using the solution provided in the embodiments of this application for file access, the first file directory in the local file system is first mapped to the second file directory in the file system of the second device. In this way, the target application in the second device can access the first file directory through the second file directory and determine the target file in the first file directory to be accessed. Then, the second device can send an access request for the target file to the first device. The first device can respond to the access request, so that the target application in the second device can successfully access the target file in the first device, thus realizing cross-device file access.

[0193] Furthermore, after receiving an access request for the target file from the second device, the first device further determines whether to respond to the access request based on the access permissions of the target application on the second device and whether the target application is a trusted signature program. Specifically, if the target file is a file that the target application is allowed to access, the access request is responded to; otherwise, the application is further assessed for its trusted signature program status, and only if it is a trusted signature program is the access request responded to. It is evident that in responding to the above access requests, multiple authentications are performed on the application on the second device accessing the target file, ensuring that the access request is only responded to if the target application meets the access requirements, thus allowing the target application to access the target file. This helps filter access requests from malicious applications for the target file, thereby preventing malicious applications from stealing and distributing the target file on the first device, and improving the security of files on the first device during cross-device file access.

[0194] In one embodiment of this application, whether the target application is a trusted signing program is determined by the following method:

[0195] Obtain the signature file of the target application from the second device; if the target application is a system program and the signature file contains a system tag, then determine that the target application is a trusted signature program; if the target application is a third-party program and the signature file is valid, then verify the target application according to the signature information and verification information contained in the signature file, and if the verification is successful, determine that the target application is a trusted signature program.

[0196] As can be seen from the above, when accessing files using the solution provided in this application, a trusted application determination is performed on the target application. Only when the target application is a trusted application will the access request from the second device be responded to, allowing the target application to access the target file. This prevents untrusted applications from accessing target files on the first device, thus improving the security of target files on the first device during file access.

[0197] In addition, the system application is an application developed internally by the first equipment manufacturer and has been certified, so its credibility is relatively high; in contrast, the third-party application is an application developed by a third-party developer, so its credibility is relatively low. The embodiments of this application can use different methods to determine whether the target application is a system program or a third-party program, so as to more reasonably and effectively determine whether the target application is a trusted signature program based on the characteristics of system programs or third-party programs.

[0198] In one embodiment of this application, whether the target file is a file that the target application is allowed to access is determined by the following method:

[0199] Obtain the process identifier of the target application from the second device; based on the process identifier, determine whether the target file is a file that the target application is allowed to access.

[0200] Since the process identifier of an application can represent information such as the user level of the process creator and the order in which the process was created, it can be used to identify a process. Therefore, using the process identifier of the target application as a basis can accurately and conveniently determine the access permissions of the target application to the target file.

[0201] In one embodiment of this application, responding to the access request includes:

[0202] Obtain the mapping path of the target file in the second file directory; if the mapping path is a valid path, respond to the access request based on the mapping path; if the mapping path is an invalid path, obtain the original path of the target file in the first file directory, repair the mapping path based on the original path, and respond to the access request based on the repaired mapping path.

[0203] As can be seen from the above, when using the solution provided in the embodiments of this application to access files, after determining that the target application located in the second device has access permissions to the target file in the first device, it can also determine whether the mapping path of the target file in the second file directory is valid. In this way, if the above mapping path is invalid, the mapping path can be repaired based on the original path of the target file in the first file directory, so that the target application can successfully access the target file. This is beneficial to improving the success rate of the target application accessing the target file when it has access permissions, and improving the efficiency of file access.

[0204] In one embodiment of this application, responding to the access request includes:

[0205] If there are multiple unresponsive requests to access the target file, determine the response order of the access requests among the other requests; if the order for responding to the access requests has not been reached, lock the access thread used to respond to the access requests; if the order for responding to the access requests has been reached, unlock the access thread, and respond to the access requests based on the access thread.

[0206] As can be seen from the above, this ensures that each access request is processed in the order of response, which helps prevent responding to multiple access requests at the same time. This avoids problems such as file data corruption caused by multiple target applications accessing the target file at the same time, and improves the stability of the file access process.

[0207] In the technical solution of this application, the operations of obtaining, storing, using, processing, transmitting, providing and disclosing user personal information are all carried out with the user's authorization.

[0208] This application also provides an electronic device, such as... Figure 5 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application. The electronic device includes:

[0209] Memory 501 is used to store computer programs;

[0210] The processor 502 is used to execute the program stored in the memory 501 to implement the file access method provided in the embodiments of this application.

[0211] Furthermore, the aforementioned electronic device may also include a communication bus and / or a communication interface, with the processor 502, communication interface, and memory 501 communicating with each other via the communication bus.

[0212] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0213] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0214] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0215] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0216] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the file access method provided in the embodiments of this application.

[0217] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the file access method provided in the embodiments of this application.

[0218] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in 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 (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0219] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0220] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the embodiments for apparatus, electronic devices, and storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0221] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A file access method, characterized in that, Applied to a first device, the method includes: Map the first file directory in the local file system to the second file directory in the file system of the second device; Upon receiving an access request for a target file from the second device, if the target file is a file that the target application is allowed to access, then the access request is responded to, wherein the target application is: the application in the second device that requests access to the target file, the target file is a file in the first file directory, and the access request is: a request generated by the target application based on the mapping path of the target file in the second file directory; Otherwise, if the target application is a trusted signing program, respond to the access request; The following methods are used to determine whether the target application is a trusted signing program: Obtain the signature file of the target application from the second device; If the target application is a system program and the signature file contains a system tag, then the target application is determined to be a trusted signature program. If the target application is a third-party program and the signature file is valid, the target application is verified based on the signature information and verification information contained in the signature file. If the verification is successful, the target application is determined to be a trusted signature program. The target file is determined to be a file that the target application is allowed to access by the following methods: Obtain the process identifier of the target application from the second device; wherein the process identifier includes: the process's UID, and / or the process's PID; the process's UID represents the user level of the process creator; the process's PID represents the process's creation order; If the process identifier includes the process's UID, and the process's UID belongs to a preset user-level UID set corresponding to the target file, then the target file is determined to be a file that the target application is allowed to access. If the process identifier includes the process's PID, and the process's PID is in a preset format, the target file is determined to be a file that the target application is allowed to access; wherein, the preset format is a format that the first device has pre-notified the second device of.

2. The method according to claim 1, characterized in that, The response to the access request includes: Obtain the mapping path of the target file in the second file directory; If the mapping path is a valid path, then the access request is responded to based on the mapping path; If the mapped path is invalid, the original path of the target file in the first file directory is obtained, the mapped path is repaired based on the original path, and the access request is responded to based on the repaired mapped path.

3. The method according to claim 1, characterized in that, The response to the access request includes: If there are multiple unanswered requests to access the target file, determine the response order of the access request among the other requests; If the order for responding to the access request is not met, the access thread used to respond to the access request is locked; When the order for responding to the access requests is reached, the access thread is unlocked, and the access request is responded to based on the access thread.

4. A file access device, characterized in that, Applied to a first device, the device includes: The file directory mapping module is used to map a first file directory in the local file system to a second file directory in the file system of the second device. The first access request response module is configured to, upon receiving an access request for a target file sent by the second device, respond to the access request if the target file is a file that the target application is allowed to access; otherwise, trigger the second access request response module. The target application is an application in the second device that requests access to the target file, the target file is a file in the first file directory, and the access request is a request generated by the target application based on the mapping path of the target file in the second file directory. The second access request response module is used to respond to the access request if the target application is a trusted signature program; The following methods are used to determine whether the target application is a trusted signing program: Obtain the signature file of the target application from the second device; if the target application is a system program and the signature file contains a system tag, then determine that the target application is a trusted signature program; if the target application is a third-party program and the signature file is valid, then verify the target application according to the signature information and verification information contained in the signature file, and if the verification is successful, determine that the target application is a trusted signature program. The target file is determined to be a file that the target application is allowed to access by the following methods: The process identifier of the target application is obtained from the second device; wherein the process identifier includes: the process's UID, and / or the process's PID; the process's UID represents the user level of the process creator; the process's PID represents the process's creation order; when the process identifier includes the process's UID, if the process's UID belongs to a preset user-level UID set corresponding to the target file, the target file is determined to be a file that the target application is allowed to access; when the process identifier includes the process's PID, if the process's PID is in a preset format, the target file is determined to be a file that the target application is allowed to access; wherein the preset format is notified to the second device in advance by the first device; when the process identifier includes the process's UID and the process's PID, if the process's UID belongs to a preset user-level UID set corresponding to the target file, and / or the process's PID is in a preset format, the target file is determined to be a file that the target application is allowed to access.

5. The apparatus according to claim 4, characterized in that, The response to the access request includes: Obtain the mapping path of the target file in the second file directory; if the mapping path is a valid path, respond to the access request based on the mapping path; if the mapping path is an invalid path, obtain the original path of the target file in the first file directory, repair the mapping path based on the original path, and respond to the access request based on the repaired mapping path.

6. The apparatus according to claim 4, characterized in that, The response to the access request includes: If there are multiple unresponsive requests to access the target file, determine the response order of the access requests among the other requests; if the order for responding to the access requests has not been reached, lock the access thread used to respond to the access requests; if the order for responding to the access requests has been reached, unlock the access thread, and respond to the access requests based on the access thread.

7. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-3.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-3.

Images