CN114186280A - 一种文件访问方法、计算设备及可读存储介质 - Google Patents

Abstract

本发明公开了一种文件访问方法、计算设备及可读存储介质，方法包括：当监测到正在运行的任一第一应用程序访问目标文件的操作时，判断当前运行的第一应用程序是否可信，若是，则允许当前运行的第一应用程序访问目标文件，任一第一应用程序运行于兼容层创建的任一容器中，若否，则继续判断目标文件是否为用户选中的文件，若目标文件是用户选中的文件，则允许当前运行的第一应用程序访问目标文件；若目标文件不是用户选中的文件，则弹出第一提示框，以提示用户当前运行的第一应用程序是不可信的。可知，在容器中运行未知或不可信应用程序时，可有效阻止未知或不可信应用程序破坏容器外的操作系统的文件数据，提高文件访问的安全性。

Description

一种文件访问方法、计算设备及可读存储介质

技术领域

本发明涉及计算机领域，尤其涉及一种文件访问方法、计算设备及可读存储介质。

背景技术

已有技术中，为了推动Linux操作系统替代Windows操作系统的步伐，多通过wine技术将Windows操作系统的应用程序迁移至Linux操作系统中。Wine技术的工作过程为：创建一个干净的wine容器，在创建wine容器时宿主机的Linux操作系统的部分目录映射到wine容器中，之后在该容器中运行Windows 应用程序，运行中的Windows应用程序可通过访问映射目录中的文件目录访问宿主机的文件。

但是上述通过wine技术实现应用程序迁移的过程中，各个wine容器中运行的Windows应用程序由于可以访问已映射的、Linux操作系统目录的文件，所以若wine容器的Windows应用程序感染了病毒时，大概率会导致Linux操作系统的数据丢失和泄密，严重破坏了企业和个人重要文件数据的数据安全性。

为了解决上述问题，方法之一是宿主机的Linux操作系统中预装一个PE文件安全扫描功能，提供安全扫描接口给wine容器，wine容器在运行Windows应用程序时，通过调用安全扫描接口确认当前运行的应用程序是否是恶意程序，若是，则不允许wine容器运行该Windows应用程序。另一种方法是用户运行专业的杀毒软件，通过该杀毒软件定期扫描宿主机的Linux操作系统中是否存在恶意软件，如果存在恶意软件，将其隔离或删除。但是，已有方案仅可防止目前已经存在的病毒破坏数据的安全性，无法避免感染了新病毒的应用程序访问宿主机的文件，从而已有的方法无法很好的避免病毒破坏数据，即在迁移操作系统后，宿主机的数据安全性无法得到保证。

发明内容

为此，本发明提供了一种文件访问方法，以力图解决上述技术问题。

根据本发明的一个方面，提高一种文件访问方法，适于在计算设备的第一操作系统的兼容层中执行，兼容层适于运行第一应用程序，第一应用程序所需的运行环境为第二操作系统，所述方法包括：响应于监测到正在运行的任一第一应用程序访问目标文件的操作，判断当前运行的第一应用程序是否可信，若是，则允许当前运行的第一应用程序访问目标文件，其中，目标文件为第一操作系统中、已映射至兼容层的文件，任一第一应用程序运行于所述兼容层创建的任一容器中；若否，则继续判断目标文件是否为用户选中的文件，若目标文件是用户选中的文件，则允许当前运行的第一应用程序访问目标文件；若目标文件不是用户选中的文件，则弹出第一提示框，以提示用户当前运行的第一应用程序是不可信的。

可选地，兼容层中存储有应用程序开发商白名单，判断当前运行的第一应用程序是否可信的步骤包括：通过白名单判断当前运行的第一应用程序是否可信。

可选地，通过白名单判断当前运行的第一应用程序是否可信的步骤包括：判断当前运行的第一应用程序是否存在文件签名，若存在，获取该第一应用程序的文件签名，作为第一文件签名；验证第一文件签名是否有效，若有效，则从第一文件签名中获取该第一应用程序对应的开发商信息，作为第一信息；判断是否从白名单中查找到所述第一信息，若是，则判定该第一应用程序是可信的。

可选地，兼容层中还存储有地址文件，地址文件中任一数据项与用户选中的、已映射至兼容层的所述第一操作系统的文件路径一一对应，继续判断目标文件是否为用户选中的文件的步骤包括：获取目标文件的路径，作为第一路径；判断是否从地址文件中查找到第一路径，若是，则继续判断目标文件是否为用户选中的文件。

可选地，地址文件中任一数据项为压缩后的路径，本发明提供的文件访问方法还包括步骤：压缩第一路径，作为第二路径；其中，判断是否从地址表中查找到第一路径的步骤包括：判断是否从地址文件中查找到第二路径。

可选地，本发明提供的文件访问方法，通过预设压缩算法对所述第一路径的字符串进行压缩，得到第二路径。

可选地，本发明提供的文件访问方法还包括步骤：响应于监测到选中文件浏览对话框中文件的操作，获取已选中文件的文件路径；压缩文件路径的字符串，得到第一地址；将地址文件中的数据更新为第一地址。

可选地，第一提示框中包括允许访问按钮和不允许访问按钮，本发明提供的文件访问方法还包括步骤：当监测到选择第一提示框中允许访问按钮的操作时，则允许当前第一应用程序访问目标文件。

可选地，第一操作系统为Linux操作系统，第二操作系统为Windows操作系统。

可选地，兼容层为wine容器。

根据本发明的又一个方面，提供一种计算设备，包括：至少一个处理器；以及存储器，存储有程序指令，其中，程序指令被配置为适于由至少一个处理器执行，程序指令包括用于执行根据本发明的文件访问方法的指令。

根据本发明的又一个方面，提供一种存储有程序指令的可读存储介质，当程序指令被计算设备读取并执行时，使得计算设备执行根据本发明的文件访问方法。

根据本发明的文件访问方法，当监测到正在兼容层已创建的任一容器中运行的任一第一应用程序访问目标文件的操作时，首先判断当前运行的第一应用程序是否可信，若是，说明当前运行在任一容器中的第一应用程序为安全的，则允许当前运行的第一应用程序访问目标文件，若当前运行在任一容器中的的第一应用程序不可信时，监控用户打开文件浏览对话框或鼠标拖放来识别是用户主动访问文件，还是后台进程静默访问文件，如果是后台进程静默访问，则阻止并给予危险提示，若不是，则允许当前运行的第一应用程序访问目标文件。由此可知，在容器中运行未知或不可信应用程序时，可有效阻止未知或不可信应用程序破坏宿主机的操作系统的文件数据，提高文件访问的安全性，且对用户的使用体验没有影响。

附图说明

为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。

图1示出了根据本发明一个实施例的计算设备100的结构框图；

图2示出了根据本发明一个实施例的文件访问方法200的流程图；

图3示出了根据本发明一个实施例的容器原生目录的示意图；

图4示出了根据本发明一个实施例的包括已映射部分第一操作系统文件目录的容器目录的示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

目前Linux操作系统桌面市场使用率低，应用程序开发量少，很少有独立软件生产商为其开发Linux原生应用程序。但是，将Windows操作系统的应用程序迁移到Linux操作系统之后，存在大量的应用程序无法使用的问题，严重影响Linux操作系统替代Windows操作系统的进程，进而阻碍了Linux操作系统桌面的发展以及国产化操作系统平台的普及和推广。

为了推动Linux操作系统替代Windows操作系统的进程，多通过wine技术将Windows操作系统的应用程序迁移至Linux操作系统中。wine技术是一个能够在多种兼容操作系统（例如 Linux、Mac 、OSX及BSD等）上运行 Windows 应用程序的兼容层。wine技术不是类似虚拟机一样模仿整个 Windows操作系统，而是将Windows API调用动态转成本机的操作系统调用，相对虚拟机方式来说消耗的内存大大减少，性能几乎与在Windows操作系统上运行一样。

wine技术在设计上考虑了容器隔离，即每个Windows应用程序必须运行在一个指定的wine容器中，不同容器的Windows应用程序无法相互通信，一个容器就相当于一个轻量级的Windows操作系统运行环境。wine技术的工作过程为：创建一个干净的wine容器，为了方便用户读写Linux操作系统的本地磁盘文件，使得用户在操作Windows应用程序可以实现原生的使用体验，在创建wine容器时会把Linux操作系统的部分目录映射至容器的容器目录中，以使得运行在容器中的Windows应用程序可以访问Linux操作系统的部分文件。之后在该容器中安装Windows 应用程序，并运行安装好的应用程序后，Windows 应用程序可通过访问容器目录中的文件路径访问宿主机的文件。

表1给出了Linux操作系统的部分文件目录与映射至容器目录后的文件目录对应表。

Linux操作系统的部分文件目录	映射至容器目录的文件目录
		当前用户名目录	Z盘
系统根目录	Y盘
		当前用户名目录下的Videos目录	C盘/users/用户名/My Videos
当前用户名目录下的Pictures目录	C盘/users/用户名/My Pictures
		当前用户名目录下的Music目录	C盘/users/用户名/My Music
当前用户名目录下的Downloads目录	C盘/users/用户名/Downloads
		当前用户名目录下的Documents目录	C盘/users/用户名/My Documents
当前用户名目录下的Desktop目录	C盘/users/用户名/Desktop

但是上述通过wine技术实现应用程序迁移的过程中，各个wine容器中运行的Windows应用程序可以访问已映射的、Linux操作系统目录的文件，所以若wine容器的Windows应用程序感染了病毒时，那么不仅wine容器内的文件被破坏，已映射的、Linux操作系统目录包含的重要文件也可能被破坏，并且可以通过这种机制传播到其他容器，这就会导致数据丢失和泄密，严重破坏了企业和个人重要文件数据的数据安全性。

为了解决上述问题，方法之一是在宿主机的Linux操作系统中预装一个PE文件安全扫描功能，提供安全扫描接口给wine容器，wine容器在运行Windows应用程序时，通过调用安全扫描接口确认当前运行的应用程序是否是恶意程序，若是，就则不允许wine容器运行该Windows应用程序。例如，统信UOS专业版1040自带的安全中心，提供了瑞星杀毒安全扫描接口给外部程序调用。另一种方法是用户运行专业的杀毒软件，通过该杀毒软件定期扫描操作系统中是否存在恶意软件，如果存在恶意软件，将其隔离或删除。

但是，已有方案仅可防止感染了已经存在的病毒的应用程序访问宿主机文件，对于感染了新病毒的应用程序，是无法避免其访问宿主机文件的，只能事后预防。从而已有的方法无法很好的避免病毒破坏数据，即在迁移操作系统后，降低宿主机的数据安全性。

为了解决上述问题，本发明提供了一种文件访问方法，该方法适于在运行于计算设备上的操作系统中执行，进一步地，适于在运行于操作系统上的兼容层中执行。图1示出了根据本发明一个实施例的计算设备100的结构框图。

需要说明的是，图1所示的计算设备100仅为一个示例，在实践中，用于实施本发明的文件访问方法的计算设备可以是任意型号的设备，其硬件配置情况可以与图1所示的计算设备100相同，也可以与图1所示的计算设备100不同。实践中用于实施本发明的文件访问方法的计算设备可以对图1所示的计算设备100的硬件组件进行增加或删减，本发明对计算设备的具体硬件配置情况不做限制。

如图1所示，在基本配置102中，计算设备100典型地包括系统存储器106和一个或者多个处理器104。存储器总线108可以用于在处理器104和系统存储器106之间的通信。

取决于期望的配置，处理器104可以是任何类型的处理，包括但不限于：微处理器（µP）、微控制器（µC）、数字信息处理器（DSP）或者它们的任何组合。处理器104可以包括诸如一级高速缓存110和二级高速缓存112之类的一个或者多个级别的高速缓存、处理器核心114和寄存器116。示例的处理器核心114可以包括运算逻辑单元（ALU）、浮点数单元（FPU）、数字信号处理核心（DSP核心）或者它们的任何组合。示例的存储器控制器118可以与处理器104一起使用，或者在一些实现中，存储器控制器118可以是处理器104的一个内部部分。

取决于期望的配置，系统存储器106可以是任意类型的存储器，包括但不限于：易失性存储器（诸如RAM）、非易失性存储器（诸如ROM、闪存等）或者它们的任何组合。计算设备中的物理内存通常指的是易失性存储器RAM，磁盘中的数据需要加载至物理内存中才能够被处理器104读取。系统存储器106可以包括操作系统120、一个或者多个应用122以及程序数据124。

在一些实施方式中，应用122可以布置为在操作系统上由一个或多个处理器104利用程序数据124执行指令。操作系统120例如可以是Linux、Windows等，其包括用于处理基本系统服务以及执行依赖于硬件的任务的程序指令。应用122包括用于实现各种用户期望的功能的程序指令，应用122例如可以是兼容层、即时通讯软件、软件开发工具（例如集成开发环境IDE、编译器等）等，但不限于此。当应用122被运行到计算设备100中时，可以向操作系统120添加驱动模块。

在计算设备100运行时，处理器104会从系统存储器106中读取操作系统120的程序指令并执行。应用122运行在操作系统120之上，利用操作系统120以及底层硬件提供的接口来实现各种用户期望的功能。当用户运行应用122时，应用122会加载至系统存储器106中，处理器104从系统存储器106中读取并执行应用122的程序指令。

计算设备100还包括储存设备132，储存设备132包括可移除储存器136和不可移除储存器138，可移除储存器136和不可移除储存器138均与储存接口总线134连接。

计算设备100还可以包括有助于从各种接口设备（例如，输出设备142、外设接口144和通信设备146）到基本配置102经由总线/接口控制器130的通信的接口总线140。示例的输出设备142包括图形处理单元148和音频处理单元150。它们可以被配置为有助于经由一个或者多个A/V端口152与诸如显示器或者扬声器之类的各种外部设备进行通信。示例外设接口144可以包括串行接口控制器154和并行接口控制器156，它们可以被配置为有助于经由一个或者多个I/O端口158和诸如输入设备（例如，键盘、鼠标、笔、语音输入设备、触摸输入设备）或者其他外设（例如打印机、扫描仪等）之类的外部设备进行通信。示例的通信设备146可以包括网络控制器160，其可以被布置为便于经由一个或者多个通信端口164与一个或者多个其他计算设备162通过网络通信链路的通信。

网络通信链路可以是通信介质的一个示例。通信介质通常可以体现为在诸如载波或者其他传输机制之类的调制数据信号中的计算机可读指令、数据结构、程序模块，并且可以包括任何信息递送介质。“调制数据信号”可以这样的信号，它的数据集中的一个或者多个或者它的改变可以在信号中编码信息的方式进行。作为非限制性的示例，通信介质可以包括诸如有线网络或者专线网络之类的有线介质，以及诸如声音、射频（RF）、微波、红外（IR）或者其它无线介质在内的各种无线介质。这里使用的术语计算机可读介质可以包括存储介质和通信介质二者。

在根据本发明的计算设备100中，应用122包括用于执行本发明的文件访问方法200的指令，该指令可以指示处理器104执行本发明的文件访问方法。本领域技术人员可以理解，除了用于执行文件访问方法200的指令之外，应用122还可以包括用于实现其他功能的其他应用126。

图2示出了根据本发明一个实施例的文件访问方法200的流程图，方法200适于在运行于计算设备100（例如图1所示的计算设备100）上的操作系统中执行，进一步地，适于在操作系统提供的兼容层中执行。

计算设备中运行有第一操作系统，第一操作系统为运行在计算设备中的原生操作系统，第一操作系统提供兼容层，兼容层中运行第二操作系统的应用程序，此处的第二操作系统的应用程序，可以理解为应用程序所需的运行环境为第二操作系统。第一操作系统、第二操作系统可以根据实际应用场景进行设置，本发明对此不进行限制。例如，第一操作系统为Linux操作系统、第二操作系统为Windows操作系统。

兼容层可以根据实际应用场景进行设置，本发明对此不做限制。例如，兼容层可以为wine兼容层，wine兼容层是一个能够在多种兼容操作系统（例如 Linux、Mac、BSD等）上运行 Windows 应用程序的兼容层。wine兼容层不是类似虚拟机一样模仿整个Windows 系统，而是将Windows API调用动态转成本机的多种兼容操作系统调用，相对虚拟机方式来说消耗的内存大大减少，性能与在Windows操作系统上运行的几乎相同。

当安装了多个第二操作系统的应用程序时，第一操作系统通过兼容层创建多个容器，为了避免应用程序之间相互干扰，一般一个容器中安装并运行一个第二操作系统的应用程序，即，此时，第一操作系统的兼容层中包括多个容器，容器的个数与安装的第二操作系统的应用程序的个数相同。下述内容中将第二操作系统的应用程序统称为第一应用程序。

由上述内容可以得出，本发明提供的文件访问方法200，适于在操作系统提供的兼容层的任一容器中执行。

由上述内容可知，任一容器对应有一个容器目录，运行在该容器中的第一应用程序仅可访问其所在容器的容器目录中的文件，该容器目录中可包括容器的原生目录（容器的原生目录如图3所示）和已映射至容器目录的部分第一操作系统的文件目录，即，此时运行在该容器中的应用程序可访问容器原生目录的文件和部分已映射至容器目录的第一操作系统的文件。其中，包括容器的原生目录和已映射至容器目录的部分第一操作系统的文件目录的容器目录如图4所示，其中，4-1为已映射至容器目录的部分第一操作系统的文件目录，其余部分为容器的原生目录。

各容器中除了存储有一个容器目录外，还存储有一个白名单和一个地址文件。白名单中记录有运行在容器中的应用程序的开发商白名单。地址文件中任一数据项与用户选中的、已映射至兼容层的第一操作系统的文件路径一一对应。地址文件的任一数据项为压缩后的路径，压缩方式可以根据实际应用场景进行设置，本发明对此不进行限制。例如，通过压缩算法对文件路径进行压缩，进一步地，压缩算法可以为MD5算法。

以当前登录至第一应用程序的用户为frank为例，地址文件中frank用户选中的原始文件路径如表2中第一列所示，通过MD5算法对原始文件路径的字符串进行压缩后得到的压缩路径如表2中第二列所示。

表2

原始文件路径	压缩后的文件路径
		/home/frank/Pictures/	72ef7b34dc5d00558c350c3891e99419
/home/frank/Videos/	1090075b86e20974f5b9d36cd244f058
		/home/frank/Music/	dd4c6ced026636dca0ce60ee4997da18
/home/frank/Desktop/	6ae5c14ccb581004d0d47a66b3b2ed57
		/home/frank/Downloads/	16eeeb70655d5baf20953695e4b8d08e
/home/frank/Documents/	5913836eba1a6c9296152302f75d3490

在一个实施方式中，通过MD5算法对原始文件路径的字符串进行压缩后得到压缩路径的关键性代码示例如下：

template<typename HT>

void md5_init(MD5_STATE<HT>* state) {

state->A = 0x67452301;

state->B = 0xefcdab89;

state->C = 0x98badcfe;

state->D = 0x10325476;

}

#ifdef __AVX512VL__

#include <immintrin.h>

template<>

void md5_init<__m128i>(MD5_STATE<__m128i>* state) {

state->A = _mm_cvtsi32_si128(0x67452301);

state->B = _mm_cvtsi32_si128(0xefcdab89);

state->C = _mm_cvtsi32_si128(0x98badcfe);

state->D = _mm_cvtsi32_si128(0x10325476);

}

#endif

template<typename HT, void(&fn)(MD5_STATE<HT>*, const void*)>

void md5(MD5_STATE<HT>* state, const void* __restrict__ src, size_tlen) {

md5_init<HT>(state);

char* __restrict__ _src = (char* __restrict__)src;

uint64_t totalLen = len << 3; // length in bits

for(; len >= 64; len -= 64) {

fn(state, _src);

_src += 64;

}

len &= 63;

// finalize

char block[64];

memcpy(block, _src, len);

block[len++] = 0x80;

// write this in a loop to avoid duplicating the force-inlinedprocess_block function twice

for(int iter = (len <= 64-8); iter < 2; iter++) {

if(iter == 0) {

memset(block + len, 0, 64-len);

len = 0;

} else {

memset(block + len, 0, 64-8 - len);

memcpy(block + 64-8, &totalLen, 8);

}

在一个实施方式中，地址文件可以实现为地址表，wine容器生成地址表的过程也可以理解为更新地址表的过程，更新地址表的具体实现方式如下：

响应用户触发弹出文件浏览对话框接口的操作，弹出文件浏览对话框，文件浏览对话框中包括多个文件名（即文件路径），用户通过鼠标的拖动操作选中一个或多个文件路径后，遍历用户选中的文件路径，并将文件路径通过压缩算法进行压缩，得到与选中的文件路径对应的压缩地址，将地址表的内容更新为当前得到的压缩地址。文件浏览对话框中的多个文件名称可以以列表形式显示。

以第二操作系统为Windows操作系统为例，对更新地址表的具体实现方式进行说明：

首先，由于Windows应用程序弹出文件浏览对话框都是调用comdlg32模块的GetOpenFileNameA和GetOpenFileNameW函数来实现的。所以，在遍历用户选中的文件路径时，只需改造wine的comdlg32模块的GetOpenFileNameA和GetOpenFileNameW函数，在确定用户选中的文件后，遍历OPENFILENAMEA和OPENFILENAMEW结构体的lpstrFile成员指向的内存块，每监测到一个NULL字符就是一个文件名的过程结束，遇到连续两个NULL字符，该标志表示遍历当前选中文件的过程结束。

之后，由于Windows应用程序获取鼠标拖放的文件名列表，都是调用shell32模块的DragQueryFileA和DragQueryFileW函数来实现的。所以，在将地址表的内容更新为当前得到的压缩地址的过程中，只需改造wine容器（第一应用程序所对应的wine容器）的shell32模块的DragQueryFileA和DragQueryFileW函数即可。在获取用户选中的文件名后进行压缩操作，得到压缩后的文件路径，覆盖到short_table_for_select_files表（即地址表）中。

在一个实施方式中，更新地址表的关键性代码示例如下：

typedef struct tagOFNA {

DWORD lStructSize;

HWND hwndOwner;

HINSTANCE hInstance;

LPCSTR lpstrFilter;

LPSTR lpstrCustomFilter;

DWORD nMaxCustFilter;

DWORD nFilterIndex;

LPSTR lpstrFile;

DWORD nMaxFile;

LPSTR lpstrFileTitle;

DWORD nMaxFileTitle;

LPCSTR lpstrInitialDir;

LPCSTR lpstrTitle;

DWORD Flags;

WORD nFileOffset;

WORD nFileExtension;

LPCSTR lpstrDefExt;

LPARAM lCustData;

LPOFNHOOKPROC lpfnHook;

LPCSTR lpTemplateName;

LPEDITMENU lpEditInfo;

LPCSTR lpstrPrompt;

void *pvReserved;

DWORD dwReserved;

DWORD FlagsEx;

} OPENFILENAMEA, *LPOPENFILENAMEA;

UINT WINAPI DragQueryFileA(

HDROP hDrop,

UINT lFile,

LPSTR lpszFile,

UINT lLength)

{

LPSTR lpDrop;

UINT i = 0;

DROPFILES *lpDropFileStruct = GlobalLock(hDrop);

TRACE("(%p, %x, %p, %u)\n", hDrop,lFile,lpszFile,lLength);

if(!lpDropFileStruct) goto end;

lpDrop = (LPSTR) lpDropFileStruct + lpDropFileStruct->pFiles;

if (0 == lFile) {

char* path = lpDrop;

int i = 0;

memset(short_table_for_selected_files, 0, sizeof(short_table_for_selected_files));

while (*path != 0 && *(path+1) != 0 && i < MAX_FILES) {

md5sum(path, short_table_for_selected_files[i])

++i;

path += strlen(path) + 1;

}

}

如图2所示，该方法200包括步骤S210至步骤S260。首先执行步骤S210，监测运行在当前容器中的第一应用程序是否访问目标文件，当任一容器监测到运行在其中的第一应用程序访问目标文件（目标文件为第一操作系统的文件）的操作时，执行步骤S220，判断当前运行的第一应用程序是否可信，若是，则执行步骤S260，若否，执行步骤S230。

具体地，判断当前运行的第一应用程序是否存在文件签名，若存在，获取该第一应用程序的文件签名，作为第一文件签名，验证第一文件签名是否有效。若有效，则从第一文件签名中获取该第一应用程序对应的开发商信息，作为第一信息，判断是否从白名单中查找到第一信息，若是，则判定该第一应用程序是可信的。其中，开发商信息可以根据实际应用场景进行设置，本发明对此不进行限制，例如开发商信息可以为开发商名称。其中，验证第一文件签名是否有效的方式可以根据实际应用场景进行设置，本发明对此不进行限制。例如，可以通过加密算法验证文件签名是否有效，进一步地，加密算法可以为RSA加密算法。

同样以第二操作系统为Windows操作系统为例，由于Windows应用程序访问文件，都是调用kernel32模块的CreateFileA和CreateFileW函数来实现的。所以，只需改造wine容器（第一应用程序所对应的wine容器）的kernel32模块的CreateFileA和CreateFileW函数，在这两个函数的最开始位置，先检查g_trust_app 变量是否是可信程序，如果是可信程序，直接执行步骤S260，以继续执行打开目标文件的流程。

由于Window应用程序多以PE文件格式存储，因此第一应用程序对应的可执行文件为PE文件，那么第一文件签名可以为PE文件签名，PE文件签名可以存储于第一应用程序的PE文件中。

例如，获取第一应用程序对应的开发商信息的步骤为：

定义一个可信应用程序开发商名称的sha1摘要列表g_trusted_vendor，该列表的没有数据项对应一个可信应用程序开发商名单，可以从各应用程序开发商的官网下载系列软件的安装程序，从应用程序的PE文件签名的信息中提取开发商信息。以应用程序微信为例，其主程序WeChat.exe的PE文件签名的信息如下：

C=CN，S=Guangdong，L=Shenzhen，O=Tencent Technology(Shenzhen) CompanyLimited，OU=aa， CN=Tencent Technology(Shenzhen) Company Limited

其中，字段C表示国家，字段S表示州或省份，字段L表示本地名，字段O表示应用程序开发商名称，字段OU表示应用程序开发商业务部门单元名称，字段CN表示通用名commonname。因此微信应用程序的开发商名称就是O字段的值：Tencent Technology(Shenzhen)Company Limited。

在一个实施方式中，以第一文件签名为PE文件签名、通过RSA加密算法验证文件签名是否有效为例，对验证文件签名算法有效的步骤进行说明：

首先，从PE文件中读取数字证书（该数字证书为应用程序发送方对第一应用程序的PE文件通过加密算法进行加密的公钥的数字证书），基于该数字证书的证书链信息，逐个验证该数字证书的证书链的有效性，若所有证书链均有效，说明该数字证书是有效的，那么可以对PE文件签名进行解密。若否，则说明该数字证书是无效的，为了保证数据的安全性，不对PE文件签名进行解密。

接着，通过有效的数字证书的公钥解密PE文件签名，得到PE文件的信息摘要，作为第一信息摘要。继续通过hash（哈希）计算PE文件的信息摘要，作为第二信息摘要，判断第一信息摘要与第二信息摘要是否相等，若是，说明PE文件签名的有效的。

需要说明的是，上述仅是给出了一种RSA加密算法验证PE签名是否有效。在实际中，也可以采用其他的方法，例如基于AES的方法，对此本发明不作具体限定。

根据本发明的一个实施例，判断当前运行的第一应用程序是否可信的关键性代码示例如下：

static BOOL g_trust_app = 0;

// values returned by the program to indicate the status of theverification

#define VERIFICATION_STATUS_OK 0

#define VERIFICATION_STATUS_INVALID_SIGNATURE 1

#define VERIFICATION_STATUS_NO_SIGNATURE 2

#define VERIFICATION_STATUS_FILE_ACCESS_ERROR 3

#define VERIFICATION_STATUS_NO_PROVIDER 4

#define VERIFICATION_STATUS_UNKNOWN_ERROR 5

LPTSTR get_cert_owner(PCCERT_CONTEXT pCertCtx)

{

DWORD dwStrType;

DWORD dwCount;

LPTSTR szSubjectRDN = NULL;

dwStrType = CERT_X500_NAME_STR;

dwCount = CertGetNameString(pCertCtx,

CERT_NAME_RDN_TYPE,

0,

&dwStrType,

NULL,

0);

if (dwCount)

{

szSubjectRDN = (LPTSTR) LocalAlloc(0, dwCount * sizeof(TCHAR));

CertGetNameString(pCertCtx,

CERT_NAME_RDN_TYPE,

0,

&dwStrType,

szSubjectRDN,

dwCount);

}

return szSubjectRDN;

}

int verify_pe_sign(WCHAR* pefile)

{

GUID guidAction = WINTRUST_ACTION_GENERIC_VERIFY_V2;

WINTRUST_FILE_INFO sWintrustFileInfo;

WINTRUST_DATA sWintrustData;

HRESULT hr;

int status = VERIFICATION_STATUS_UNKNOWN_ERROR;

memset((void*)&sWintrustFileInfo, 0x00, sizeof(WINTRUST_FILE_INFO));

memset((void*)&sWintrustData, 0x00, sizeof(WINTRUST_DATA));

sWintrustFileInfo.cbStruct = sizeof(WINTRUST_FILE_INFO);

sWintrustFileInfo.pcwszFilePath = pefile;

sWintrustFileInfo.hFile = NULL;

sWintrustData.cbStruct = sizeof(WINTRUST_DATA);

sWintrustData.dwUIChoice = WTD_UI_NONE;

sWintrustData.fdwRevocationChecks = WTD_REVOKE_NONE;

sWintrustData.dwUnionChoice = WTD_CHOICE_FILE;

sWintrustData.pFile = &sWintrustFileInfo;

sWintrustData.dwStateAction = WTD_STATEACTION_VERIFY;

hr = WinVerifyTrust((HWND)INVALID_HANDLE_VALUE, &guidAction, &sWintrustData);

if (TRUST_E_NOSIGNATURE == hr)

{

status = VERIFICATION_STATUS_NO_SIGNATURE;

}

else if (CRYPT_E_FILE_ERROR == hr)

{

status = VERIFICATION_STATUS_FILE_ACCESS_ERROR;

}

else if (TRUST_E_BAD_DIGEST == hr)

{

status = VERIFICATION_STATUS_INVALID_SIGNATURE;

}

else if (TRUST_E_PROVIDER_UNKNOWN == hr)

{

status = VERIFICATION_STATUS_NO_PROVIDER;

}

else if (S_OK != hr)

{

status = VERIFICATION_STATUS_UNKNOWN_ERROR;

}

else

{

status = VERIFICATION_STATUS_OK;

// retreive the signer certificate and display itsinformation

CRYPT_PROVIDER_DATA const *psProvData = NULL;

CRYPT_PROVIDER_SGNR *psProvSigner = NULL;

CRYPT_PROVIDER_CERT *psProvCert = NULL;

FILETIME localFt;

SYSTEMTIME sysTime;

psProvData = WTHelperProvDataFromStateData(sWintrustData.hWVTStateData);

if (psProvData)

{

psProvSigner = WTHelperGetProvSignerFromChain((PCRYPT_PROVIDER_DATA)psProvData, 0 , FALSE, 0);

if (psProvSigner)

{

FileTimeToLocalFileTime(&psProvSigner->sftVerifyAsOf,&localFt);

FileTimeToSystemTime(&localFt, &sysTime);

TRACE("Signature Date = %.2d/%.2d/%.4d at %.2d:%2.d:%.2d\n",

sysTime.wDay, sysTime.wMonth,sysTime.wYear,sysTime.wHour,sysTime.wMinute,sysTime.wSecond);

psProvCert = WTHelperGetProvCertFromChain(psProvSigner, 0);

if (psProvCert)

{

LPTSTR owner = get_cert_owner(psProvCert->pCert);

if (owner)

{

TRACE("Developer Signer = %s\n", owner);

g_trust_app = is_developer_trust(owner);

LocalFree(owner);

}

}

}

}

}

sWintrustData.dwUIChoice = WTD_UI_NONE;

sWintrustData.dwStateAction = WTD_STATEACTION_CLOSE;

WinVerifyTrust((HWND)INVALID_HANDLE_VALUE, &guidAction, &sWintrustData);

return status;

}

/********************************************************************

* load_main_exe

*/

NTSTATUS load_main_exe( const WCHAR *dos_name, const char *unix_name,const WCHAR *curdir,

WCHAR **image, void **module )

{

enum loadorder loadorder = LO_INVALID;

UNICODE_STRING nt_name;

WCHAR *tmp = NULL;

BOOL contains_path;

NTSTATUS status;

SIZE_T size;

struct stat st;

WORD machine;

verify_pe_sign(dos_name);

由于病毒或者恶意程序破坏文件，是通过调用API在后台悄悄扫描磁盘文件，然后感染或损坏扫描到的文件，因此为了过滤掉病毒或恶意程序的后台扫描带来的破坏，在当前运行的第一应用程序不可信时，执行步骤S230，判断目标文件是否为用户选中的文件，以识别是用户主动访问目标文件，还是后台进程静默访问目标文件，其中，目标文件为第一操作系统中、已映射至兼容层的容器目录的文件。

具体地，获取目标文件的路径，作为第一路径，压缩第一路径，作为第二路径。判断是否从地址文件中查找到第二路径，若是，说明目标文件为用户选中的文件，即是用户主动选择的文件，继续执行步骤S260，若否，说明目标文件并不是用户选中的文件，此时为后台进程静默访问文件，为了过滤掉病毒或恶意程序的后台扫描带来的破坏，继续执行步骤S240。

例如，如果当前运行的应用程序不是可信应用程序，那么先对目标文件路径进行压缩操作，得到目标文件的压缩地址，随后遍历short_table_for_select_files 表（即地址表），判断地址表中是否存在目标文件的压缩地址，若存在，就表示该文件是用户最近一次选中的文件，直接执行步骤S260，以继续执行打开目标文件的流程。如果不存在，执行步骤S240。

由上述内容可知，在当前运行的第一应用程序不可信时，识别是用户主动访问目标文件，还是后台进程静默访问目标文件，若目标文件为用户选中的文件，即是用户主动选择的文件，才可允许当前运行的第一应用程序访问目标文件，若否，说明此时为后台进程静默访问文件，为了过滤掉病毒或恶意程序的后台扫描带来的破坏，则阻止访问目标文件，从而提高文件访问的安全性。

并且，由于地址文件中的路径为压缩路径，所占内存资源少，因此可以提高遍历地址文件的速度，进而提高文件访问的效率。

随后执行步骤S240，弹出第一提示框，以提示用户当前运行的第一应用程序是不可信的，即，提示用户当前运行的应用程序存在一定的危险性，可能破坏第一操作系统的文件数据的安全性。

其中，第一提示框可以为警告对话框，第一提示框的内容只要起到提醒用户当前运行的应用程序存在危险即可，本发明对其不进行限制。例如，第一提示框的内容可以为“未知程序正在访问容器外文件，该访问可能破坏你的文件数据，是否允许其访问”。需要说明的是，第一提示框中包括允许访问按钮和不允许访问按钮。

弹出第一提示框后，继续执行步骤S250，判断是否监测到用户选择第一提示框中的允许访问按钮，若是，即当监测到用户选择第一提示框中允许访问按钮的操作时，响应该操作，执行步骤S260，允许当前运行的第一应用程序访问目标文件。若当监测到用户选择第一提示框中不允许访问按钮的操作时，响应该操作，不访问目标文件，并继续执行步骤S210，监测运行在当前容器中的第一应用程序是否访问目标文件。

至此，便实现了在wine容器中运行的、第二操作系统的应用程序针对第一操作系统的文件的安全访问。每当任一wine容器中运行的、第二操作系统的应用程序将要访问第一操作系统的文件时，均执行步骤S210至步骤S260。

在一个实施方式中，当监测到用户选中当前显示的对话框中文件的操作，响应该操作，将地址文件更新为当前选中的文件名对应的压缩文件路径。具体实现过程如上所述，此处不再赘述。

由上述内容可知，根据本发明的文件访问方法，当监测到正在兼容层已创建的任意容器中运行的任一第一应用程序访问目标文件的操作时，首先判断当前运行的第一应用程序是否可信，若是，说明当前运行在任一容器中的第一应用程序为安全的，则允许当前运行的第一应用程序访问目标文件，若当前运行在任一容器中的第一应用程序不可信时，监控用户打开文件浏览对话框或鼠标拖放来识别是用户主动访问文件，还是后台进程静默访问文件，如果是后台进程静默访问，存在一定的风险，则阻止并给予危险提示，若不是，则允许当前运行的第一应用程序访问目标文件。由此可知，在容器中运行未知或不可信应用程序时，可有效阻止这些应用程序破坏容器外的操作系统的文件数据，提高文件访问的安全性，且对用户的使用体验没有影响。

并且，由于地址文件中的路径为压缩路径，所占内存资源少，因此可以提高遍历地址文件的速度，进而提高文件访问的效率。

这里描述的各种技术可结合硬件或软件，或者它们的组合一起实现。从而，本发明的方法和设备，或者本发明的方法和设备的某些方面或部分可采取嵌入有形媒介，例如可移动硬盘、U盘、软盘、CD-ROM或者其它任意机器可读的存储介质中的程序代码(即指令)的形式，其中当程序被载入诸如计算机之类的机器，并被所述机器执行时，所述机器变成实践本发明的设备。

在程序代码在可编程计算机上执行的情况下，计算设备一般包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)，至少一个输入装置，和至少一个输出装置。其中，存储器被配置用于存储程序代码；处理器被配置用于根据该存储器中存储的所述程序代码中的指令，执行本发明的文件访问方法。

以示例而非限制的方式，可读介质包括可读存储介质和通信介质。可读存储介质存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在可读介质的范围之内。

在此处所提供的说明书中，算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与本发明的示例一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。

此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。

如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。

尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (10)

1.一种文件访问方法，适于在计算设备的第一操作系统的兼容层中执行，所述兼容层适于运行第一应用程序，所述第一应用程序所需的运行环境为第二操作系统，所述方法包括：

响应于监测到正在运行的任一第一应用程序访问目标文件的操作，判断当前运行的第一应用程序是否可信，若是，则允许当前运行的第一应用程序访问目标文件，其中，所述目标文件为所述第一操作系统中、已映射至所述兼容层的文件，任一第一应用程序运行于所述兼容层创建的任一容器中；

若否，则继续判断所述目标文件是否为用户选中的文件，若所述目标文件是用户选中的文件，则允许当前运行的第一应用程序访问所述目标文件；

若所述目标文件不是用户选中的文件，则弹出第一提示框，以提示用户当前运行的第一应用程序是不可信的。

2.如权利要求1所述的方法，其中，所述兼容层中存储有应用程序开发商白名单，所述判断当前运行的第一应用程序是否可信的步骤包括：

通过所述白名单判断当前运行的第一应用程序是否可信。

3.如权利要求2所述的方法，其中，通过所述白名单判断当前运行的第一应用程序是否可信的步骤包括：

判断当前运行的第一应用程序是否存在文件签名，若存在，获取该第一应用程序的文件签名，作为第一文件签名；

验证所述第一文件签名是否有效，若有效，则从所述第一文件签名中获取该第一应用程序对应的开发商信息，作为第一信息；

判断是否从所述白名单中查找到所述第一信息，若是，则判定该第一应用程序是可信的。

4.如权利要求1至3中任一项所述的方法，其中，所述兼容层中还存储有地址文件，所述地址文件中任一数据项与用户选中的、已映射至兼容层的所述第一操作系统的文件路径一一对应，所述继续判断所述目标文件是否为用户选中的文件的步骤包括：

获取所述目标文件的路径，作为第一路径；

判断是否从所述地址文件中查找到所述第一路径，若是，则继续判断所述目标文件是否为用户选中的文件。

5.如权利要求4所述的方法，其中，所述地址文件中任一数据项为压缩后的路径，所述方法还包括步骤：

压缩所述第一路径，作为第二路径；

其中，所述判断是否从所述地址文件中查找到所述第一路径的步骤包括：

判断是否从所述地址文件中查找到所述第二路径。

6.如权利要求5所述的方法，其中，通过预设压缩算法对所述第一路径的字符串进行压缩，得到所述第二路径。

7.如权利要求1至3中任一项所述的方法，还包括步骤：

响应于监测到选中文件浏览对话框中文件的操作，获取已选中文件的文件路径；

压缩所述文件路径的字符串，得到第一地址；

将所述地址文件中的数据更新为所述第一地址。

8.如权利要求1至3中任一项所述的方法，其中，第一提示框中包括允许访问按钮和不允许访问按钮，所述方法还包括步骤：

当监测到选择所述第一提示框中允许访问按钮的操作时，则允许当前第一应用程序访问所述目标文件。

9.一种计算设备，包括：

至少一个处理器；以及

存储器，存储有程序指令，其中，所述程序指令被配置为适于由所述至少一个处理器执行，所述程序指令包括用于执行如权利要求1-8中任一项所述方法的指令。

10.一种存储有程序指令的可读存储介质，当所述程序指令被计算设备读取并执行时，使得所述计算设备执行如权利要求1-8中任一项所述方法。

Images