CN114816707A - 为插件运行创建沙箱环境的方法和装置以及计算设备 - Google Patents

Abstract

本发明公开了一种为插件运行创建沙箱环境的方法和装置以及计算设备。本发明的为插件运行创建沙箱环境的方法，包括：创建沙箱环境，将针对每个插件的本地目录映射到所述沙箱环境中，将宿主机的设备管理目录映射到所述沙箱环境中；对不同沙箱环境增加不同的资源限制；加载插件进程管理；接收前端传送的消息，所述消息包含插件的ID、插件的版本，并传递给所述插件进程管理；通过所述插件进程管理加载对应的插件，其中在一个沙箱环境中仅加载一个主插件及所述主插件依赖的从插件。本发明的方案，实现了插件进程资源的模块化管控，在沙箱的整个生命周期都可以实现完整的管控，且使得能够动态访问硬件资源，对磁盘读写速度和网络上下行速率进行了限制。

Description

为插件运行创建沙箱环境的方法和装置以及计算设备

本申请是2021年12月24日提交的发明专利申请2021115938518的分案申请。

技术领域

本发明涉及计算机浏览器插件运行技术领域，尤其是一种为插件运行创建沙箱环境的方法和装置、计算设备和可读存储介质。

背景技术

在目前的实践中，需要保证插件进程管理与插件的安全及资源的隔离。现有的技术方案是通过Docker隔离插件进程。Docker起源于Linux Container(LXC)技术，是目前主流的虚拟化容器方案。其提供了一套标准化的容器解决方案，设计图如图1所示。如图1所示，宿主机可以管理插件，docker提供管理插件的接口。本地资源管理器负责管理本地资源和docker容器之间的关系。插件管理及插件服务调用部分都是运行在Docker容器中。在实际开发项目中，后端插件服务器、插件进程管理及插件在编译打包后是直接部署在Docker容器中，暴露相关服务接口，前端通过服务接口来进行连接通信。

因为所有插件以及插件服务都是运行在Docker容器内，使插件仅能影响容器，不会对操作***产生影响。但以上Docker方案带来三个问题：

1，项目作为一个通用的浏览器插件解决方案，不同插件厂商、插件开发者需要的资源、权限、环境都不相同，但Docker创建出来的容器环境无法在容器创建后进行修改，因此，Docker方案在此背景下就显得不灵活。

2，插件进程管理及所有加载的插件都是运行在一个容器环境中，虽然与宿主机进行了环境的隔离，但没有实现每个插件之间完全的环境隔离。

3，无法实现硬件的热拔插，动态读取硬件资源(以银行客户为例，插件***会对U盾热拔插有需求)。

发明内容

为此，本发明提供了一种为插件运行创建沙箱环境的方法和装置、计算设备和可读存储介质，以力图解决或者至少缓解上面存在的至少一个问题。

根据本发明的一个方面，提供了一种为插件运行创建沙箱环境的方法，包括：创建沙箱环境，将针对每个插件的本地目录映射到所述沙箱环境中，，将宿主机的设备管理目录映射到所述沙箱环境中；对不同沙箱环境增加不同的资源限制；加载插件进程管理；接收前端传送的消息，所述消息包含插件的ID、插件的版本，并传递给所述插件进程管理；通过所述插件进程管理加载对应的插件，其中在一个沙箱环境中仅加载一个主插件及所述主插件依赖的从插件。

根据本发明另一方面，提供一种为插件运行创建沙箱环境的装置，包括：创建模块，用于创建沙箱环境，将针对每个插件的本地目录映射到所述沙箱环境中，将宿主机的设备管理目录映射到所述沙箱环境中；资源限制模块，用于对不同沙箱环境增加不同的资源限制；加载模块，用于加载插件进程管理；接收模块，用于接收前端传送的消息，所述消息包含插件的ID、插件的版本，并传递给所述插件进程管理；插件加载模块，用于通过所述插件进程管理加载对应的插件，其中在一个沙箱环境中仅加载一个主插件及所述主插件依赖的从插件。

根据本发明另一方面，提供一种计算设备，包括：至少一个处理器和存储有程序指令的存储器；当所述程序指令被所述处理器读取并执行时，使得所述计算设备执行上述为插件运行创建沙箱环境的方法。

根据本发明又一方面，提供一种存储有程序指令的可读存储介质，当所述程序指令被计算设备读取并执行时，使得所述计算设备执行上述为插件运行创建沙箱环境的方法。

根据本发明技术方案，实现了插件进程资源的模块化管控，且在沙箱的整个生命周期都可以实现完整的管控，并使得能够动态访问硬件资源，对磁盘读写速度和网络上下行速率进行了限制。

根据本发明技术方案的沙箱机制不需要像docker一样复杂，仅需要着重沙箱内部的实现即可，不仅使得插件的运行不会影响宿主机，还实现了插件彼此之间的环境隔离。

另外，区别于docker每次都初始化一个新进程去设置沙箱环境，根据本发明技术方案，都是在一个沙箱环境里由一个插件进程管理去加载插件，这样还能获得一个好处：每个插件都运行在一个沙箱环境里，外面的插件服务需要和插件通信时，在网络、文件***都被隔离的情况下，可以通过预留的端口穿透沙箱环境，实现通信。

附图说明

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

图1示出了通过Docker隔离插件进程的设计图。

图2示出根据本发明一个实施方式的计算设备100的示意图。

图3示出根据本发明实施方式的沙箱创建方案的总体设计图。

图4示出了根据本发明一个实施方式的为插件运行创建沙箱环境的方法400的流程图。

图5示出根据本发明实施方式的方法的并发双线程示意性流程图。

图6示出根据本发明实施方式的创建沙箱的装置的示意性框图。

具体实施方式

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

针对现有插件进程管理技术不能定制化、插件之间无法隔离等而导致无法模块化管控、不灵活等问题，本发明提供了一种为插件运行创建沙箱环境的方法，能够实现插件进程资源的模块化管控，在沙箱的整个生命周期都可以实现完整的管控，且使得能够动态访问硬件资源，对磁盘读写速度和网络上下行速率进行了限制。

本发明的为插件运行创建沙箱环境的方法在计算设备中执行。计算设备可以是任意具有存储和计算能力的设备，其例如可以实现为服务器、工作站等，也可以实现为桌面计算机、笔记本计算机等个人配置的计算机，或者实现为手机、平板电脑、智能可穿戴设备、物联网设备等终端设备，但不限于此。

图2示出了根据本发明一个实施方式的计算设备100的示意图。需要说明的是，图2所示的计算设备100仅为一个示例，在实践中，用于实施本发明的为插件运行创建沙箱环境的方法的计算设备可以是任意型号的设备，其硬件配置情况可以与图2所示的计算设备100相同，也可以与图2所示的计算设备100不同。实践中用于实施本发明的为插件运行创建沙箱环境的方法的计算设备可以对图2所示的计算设备100的硬件组件进行增加或删减，本发明对计算设备的具体硬件配置情况不做限制。

如图2所示，在基本的配置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包括用于执行本发明的为插件运行创建沙箱环境的方法400的指令，该指令可以指示处理器104执行本发明的为插件运行创建沙箱环境的方法400。在描述方法400之前，先参考图3讲述根据本发明实施方式的沙箱创建方案的总体设计思路。

在插件运行在客户机器上时，需要保证插件不会影响客户的机器，比如操作客户的敏感文件等。所以设计一个沙箱环境来隔离插件的运行。背景技术部分提到的docker是通用型的设计，不能定制。而根据本发明实施的沙箱方案能够解决这个问题。

如图3所示，在***启动时，插件服务本身会克隆沙箱，也可以说是启动沙箱进程。以后在每次调用插件(以SO为插件示例)时，会把SO置入沙箱进程里，来实现插件与宿主机环境的隔离以及插件之间的隔离。

本文以Linux操作***为例予以详细示例性描述。然而，应理解本发明不限于应用于Linux操作***，还可以兼容其他***比如Windows操作***。可以通过Linux内核的Namespace来实现环境的隔离。其中Namespaces是Linux内核用来隔离内核资源的方式。使得处于不同Namespace的进程拥有独立的全局***资源，改变一个Namespace中的***资源只会影响当前Namespace里的进程，对其他Namespace中的进程没有影响。

本沙箱方案利用到Linux内核，在进程级别利用Namespace和Cgroups功能机制，来实现插件服务之间以及插件服务与***之间的安全隔离，使不同Namespace的插件服务进程有独立的全局***资源，且不同插件服务有不同的资源限制。

在插件服务调用插件进程之前，对每个插件进程进行了全局***资源的封装隔离，隔离每个插件进程的PID(chroot进程树)、进程间通信、挂载点、网络及用户，从而完成环境隔离的配置，从而完成基础的初始化。其中，Linux***中每个文件都可以挂在到***上，如果通过Namespace进行了隔离，会把挂载点也隔离开。比如对于A文件夹，通过Namespace隔离了挂载点后，在宿主机上就看不到挂载点，只有进入虚拟环境里才能看到挂载点。隔离挂载点这一步和Changeroot(change root是改变程式执行时所参考的根目录位置)相互配合，把插件的宿主机目录映射到沙箱里面的home目录，方式是先挂载一个目录，然后通过Changeroot把这个目录指向home目录。

如图3所示以及如上所述，为每个主插件及其从插件文件创建单独的沙箱环境，使得插件的运行不会影响宿主机，且也实现了插件彼此之间的环境隔离。

图4示出了根据本发明一个实施方式的为插件运行创建沙箱环境的方法400的流程图。方法400在计算设备(例如前述计算设备100)中执行，用于模板化地管控插件进程的资源。如图4所示，方法400始于步骤S410。下面参考图4对方法400予以详细描述。

步骤S410，创建沙箱环境，将针对每个插件的本地目录映射到所述沙箱环境中，将宿主机的设备管理目录映射到所述沙箱环境中。

步骤S410描述的是初始化的第一步，即克隆一个环境隔离的进程。其本质是通过不同Namespace功能的调用，克隆了一个环境隔离的插件服务进程(沙箱进程)。

本文以Linux操作***为例予以详细示例性描述。然而，应理解本发明不限于应用于Linux操作***，还可以兼容其他***比如Windows操作***。在Linux操作***下，如果插件接口平台方案的后端都是用GO语言编写的，在此可以选择用GO语言开发沙箱，即用GO语言实现一个沙箱环境。然而应理解，也可以采用其他语言比如C、C++来编写沙箱环境，本发明在此不受限制。采用的技术手段可以是通过Linux Kernel的Namespace来实现环境的隔离。其中Namespaces是Linux内核用来隔离内核资源的方式。使得处于不同Namespace的进程拥有独立的全局***资源，改变一个Namespace中的***资源只会影响当前Namespace里的进程，对其他Namespace中的进程没有影响。

在一个可选示例中，在克隆沙箱进程之前，可以克隆插件服务，由克隆的插件服务运行后面的沙箱克隆、插件加载等过程。这样，就会在沙箱环境里存在原本插件服务的一些环境变量、镜像信息等初始配置信息，可以对该进程进行清空处理。在本实施方式中，可以采用内核的Execve***函数来置空配置信息。调用这个***函数，将指定的插件进程运行起来，替换最初的初始化(init)进程(因为复制了插件服务的进程，所以会存在一个最初的初始化的进程)。

此外，还需要针对每个插件将对应的本地目录映射到沙箱环境中。这是因为插件运行中会需要缓存，或者对文件进行读取等，所以需要为插件运行提供工作目录。然而，需要在沙箱环境里为插件提供工作目录。针对每个插件在宿主机上都建有一个目录，在沙箱初始化过程中，还可以根据文件路径规则(插件名为目录名)来做对应的change root的设置，将宿主机上的目录映射到虚拟环境里面的home目录。插件服务会根据插件ID和版本来创建对应的目录映射。其中，插件ID和版本信息来自于前端(比如浏览器)发送给插件服务的消息。在后面的步骤中，还会根据该消息加载对应的插件。

此外，为了使硬件支持热插拔，还可以通过Mount Namespace机制把宿主机的“/dev”设备管理目录映射到沙箱里，使沙箱对硬件有完整的访问权限。“/dev”目录是Linux***下，所有硬件的管理目录，比如***一个U盘，U盘的信息就挂载在dev目录里面。

S420，对不同沙箱环境增加不同的资源限制。

完成沙箱环境隔离之后，还需要对不同沙箱环境增加不同的资源限制。资源限制，指的是对每个插件进程所占据计算机资源所实行的管控，比如实行管控以使插件进程A的运行内存不超过100M，插件进程B占用CPU不超过5％等。这样就可以满足插件运行的资源要求，比如如果插件的数量比较多，就会对每个插件的资源利用率有要求，比如不允许任何插件的内存占用率超过整个***20％等。另外，如果做平台化，也需要针对不同类别的插件做限制。

在此，可采用Linux的Cgroups技术对插件进程及产生的子进程进行资源限制及控制。下面描述Cgroups技术。

Cgroups中包含了cgroup、subsystem、hierarchy三个组件，它们相互协助完成进程的资源限制。cgroup组件是对进程分组管理文档一种机制，一个cgroup包含一组进程，可以通过subsystem的各种参数配置来关联。subsystem是一组资源控制模块，包含对块设备输入输出的访问控制，设置cpu的调度策略等。hierarchy的功能是把一组cgroup串成一个树状结构，通过树结构来完成资源限制的继承。

在实际业务应用中，我们通过在cgroup上增加Linux subsystem的各种参数配置，将一组进程和一组subsystem的***参数管理起来，从而为不同插件制定不同的cgroup模板。subsystem作用于hierarchy上的cgroup节点，控制节点中进程的资源占用。所以在进行资源限制设置时，可以根据不同插件的资源使用情况(大量的磁盘IO读写、长时间的高内存占用等)来进行指定相应的模板，如内存限制模板、硬盘读写限制模板等。

因为hierarchy是将cgroup通过树状结构串起来，通过虚拟文件***的方式暴露给用户。所以在配置每个沙箱资源限制的时候，只需要对相对应的文件进行读写入即可实现。例如实现一个内存限制模板，在得到cgroup在文件***中的绝对路径后，在cgroup中的memory中创建对应的文件，配置memory.limit_in_bytes相关字段就可以实现内存限制，最后需要把这些不同的subsystem中的cgroup管理起来，并与沙箱建立关系。

S430，加载插件进程管理。

插件进程管理可以是提前写好的一个功能模块，插件服务克隆了一个沙箱环境之后，会把插件进程管理加载到克隆好的沙箱进程里面。

S440，接收前端传送的消息，所述消息包含插件的ID、插件的版本，并传递给所述插件进程管理。

经过初始化之后，得到一个空的沙箱环境，插件服务还需要向插件进程管理传送指定的消息，该消息包含插件的ID、版本等信息，以便于插件进程管理根据该消息加载对应的插件。

插件服务从前端接收该消息，前端可以是浏览器等。该消息可以包含消息ID和消息内容，其中消息ID用于区别各个消息，以便于接收方返回应答时，发送方知道该应答是针对哪个消息的。

S450，通过所述插件进程管理加载对应的插件，其中在一个沙箱环境中仅加载一个主插件及所述主插件依赖的从插件。

在创建沙箱进程之后，沙箱进程加载插件进程管理功能模块，插件进程管理再加载插件(比如SO文件)，这样就形成了一个插件进程的沙箱环境。

建立该沙箱环境的意义在于：操作***在运行不同的程序时，每个程序都是一个进程，如果在同一个环境下运行，会相互影响，比如都能操作本地文件。建立沙箱，就相当于在操作***里面又模拟了一个类似的新的操作***环境，在该新的操作***环境下来运行进程。在沙箱环境下运行的进程与外面在宿主机里运行的进程是相互隔离的，无法相互影响。在本发明实施方式中，就是把插件进程置入沙箱环境里运行，使其不会影响宿主机上其他程序的运行。

在保证硬件的安全方面，还可以限制沙箱硬件访问，具体实现手段可以是在宿主机中开发设备管理程序，通过grpc的方式与沙箱通信来予以限制。

可选地，该方法400还可以包括：建立与所述插件进程管理通信的通信端口，接收加载的插件通过所述插件进程管理进行的注册，获取相应插件的实例链接。

当插件进程管理成功加载插件后，插件可以通过比如grpc的通信方式通过插件进程管理主动注册到插件服务(即插件进程管理向插件服务发送实例信息)，插件服务获取到相应的插件实例链接来进行通信。其中，插件实例链接指的是：运行插件进程时，会向插件服务注册一个地址，调用该地址就能操作其方法和一些功能，以进行后续业务通信，比如如果插件用于图片读取，那么可以发送图片读取消息以进行相应处理等。

当在沙箱环境中成功调用插件进程管理之后，插件服务还可以获取到沙箱进程的进程ID(PID)以便于进行管理，比如对沙箱生命周期进行控制，如存活状态、退出插件等。其中PID指的是，每运行一个插件进程，都会创建一个沙箱进程，***就会给予该沙箱进程一个ID(PID)。

图5示出根据本发明实施方式的方法的并发双线程示意性流程图，其中，将创建沙箱进程的主服务与插件进程以并行的方式示出。从图5中可看出，左边的流程为插件服务所执行的主服务，右边的流程为加载插件后运行插件的插件进程。

其中，“创建沙箱”，指的是在插件服务中创建沙箱模块，而下面的“创建沙箱进程”，是该模块运行的一个步骤，表示左列为创建沙箱进程。左列沙箱创建进程包含了可选步骤“置空处理”，在其中特别示出了替换init(初始化)进程这一操作。挂载文件***指的是将设备目录/dev映射到沙箱环境中，配置namespace环境隔离，指的是沙箱通过Linux内核的***调用函数，对每个插件进程进行了全局***资源的封装隔离，隔离每个插件进程的PID(chroot进程树)、进程间通信、挂载点、网络及USER，完成基础的初始化。加载策略模板指的是如上所述的加载“内存限制模板、硬盘读写限制模板”等。

右列为加载插件后运行插件执行的插件进程。其中，插件服务建立grpc通信端口，客户端(即图2中的“插件进程管理”)准备好通信。然后，客户端向插件服务发送插件实例信息(包含端口号、插件信息)，以供插件服务之后调用插件业务功能。

其中，protobuf是Google提供的一个具有高效的协议数据交换格式工具库，除了protobuf之外，还可以采用http等通信协议，本发明在此不受限制。

创建沙箱进程是插件服务执行的过程，实际运行起来后，整个流程是插件服务和插件进程管理双向交互的过程。

通过以上描述的方法实施方式，每次插件***启动后端服务的时候会克隆一个沙箱进程，每当前端调用插件服务的时候，会在这个沙箱进程中加载插件来实现插件的隔离。基于项目需求，沙箱机制不需要像docker一样复杂，仅需要着重沙箱内部的实现，满足每个插件之间的环境资源的隔离、权限的可控即可。

另外，区别于docker每次都初始化一个新进程去设置沙箱环境，根据本实施方式的技术方案，都是在一个沙箱环境里由一个插件进程管理去加载插件，这样还能获得一个好处：每个插件都运行在一个沙箱环境里，外面的插件服务需要和插件通信时，在网络、文件***都被隔离的情况下，可以通过预留的端口穿透沙箱环境，实现通信。

下面参考图6描述根据本发明实施方式的创建沙箱的装置的示意性框图。如图6所示，该装置包括：

创建模块610，用于创建沙箱环境，将针对每个插件的本地目录映射到所述沙箱环境中，将宿主机的设备管理目录映射到所述沙箱环境中。

可选地，图6的装置可以包含：插件服务创建模块，用于创建插件服务，由创建的插件服务调用装置内的其余模块来执行沙箱克隆、插件加载等过程。该装置还可以包含：置空模块，用于对沙箱环境中创建的插件服务的初始配置信息执行清空处理。这是因为，在创建插件服务后，会在沙箱环境里存在原本插件服务的一些环境变量、镜像信息，因此需要对该进程进行清空处理。置空模块可采用内核的Execve***函数来置空配置信息。调用这个***函数，将指定的插件进程运行起来，替换最初的初始化(init)进程(因为复制了插件服务的进程，所以会存在一个最初的初始化的进程)。

如图6所示，装置包括资源限制模块620，用于对不同沙箱环境增加不同的资源限制。该模块可采用Linux的Cgroups技术对插件进程及产生的子进程进行资源限制及控制。

如图6所示，装置还包括加载模块630，用于加载插件进程管理。插件进程管理可以是提前写好的一个功能模块，插件服务克隆了一个沙箱环境之后，会把插件进程管理加载到克隆好的沙箱进程里面。

如图6所示，装置还包括接收模块640，用于接收前端传送的消息，所述消息包含插件的ID、插件的版本，并传递给所述插件进程管理。装置还包括插件加载模块650，用于通过所述插件进程管理加载对应的插件，其中在一个沙箱环境中仅加载一个主插件及所述主插件依赖的从插件。

在一个可选示例中，图6的装置还包括通信模块，用于建立与所述插件进程管理通信的通信端口，接收加载的插件通过所述插件进程管理进行的注册，获取相应插件的实例链接。所述通信模块还可以获取到沙箱进程的进程ID(PID)以便于进行管理。其中PID指的是，每运行一个插件进程，都会创建一个沙箱进程，***都会给予该沙箱进程一个ID(PID)。

关于该装置实施方式未详述部分，请参考以上方法实施方式的描述，本文不再予以赘述。

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

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

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

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

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

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施方式的描述中，本发明的各个特征有时被一起分组到单个实施方式、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。本领域技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施方式中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

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

此外，本领域的技术人员能够理解，尽管在此所述的一些实施方式包括其它实施方式中所包括的某些特征而不是其它特征，但是不同实施方式的特征的组合意味着处于本发明的范围之内并且形成不同的实施方式。此外，所述实施方式中的一些在此被描述成可以由计算机***的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施方式的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。

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

尽管根据有限数量的实施方式描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施方式。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。

Claims (6)

1.一种为插件运行创建沙箱环境的方法，在计算设备中执行，包括：

创建插件服务，所述插件服务用于执行以下步骤：

创建沙箱环境，将针对每个插件的本地目录映射到所述沙箱环境中，将宿主机的设备管理目录映射到所述沙箱环境中；

对不同沙箱环境增加不同的资源限制；

加载插件进程管理；

接收前端传送的消息，所述消息包含插件的ID、插件的版本，并传递给所述插件进程管理；

通过所述插件进程管理加载对应的插件，其中在一个沙箱环境中仅加载一个主插件及所述主插件依赖的从插件；

对所述沙箱环境进行置空处理，以清空所述插件服务存留在所述沙箱环境中的初始配置信息；以及

建立与所述插件进程管理通信的通信端口，接收加载的插件通过所述插件进程管理进行的注册，获取相应插件的实例链接。

2.如权利要求1所述的为插件运行创建沙箱环境的方法，还包括：

在加载插件进程管理之后，接收沙箱进程的ID以用于管理，其中每运行一个插件进程即产生一个沙箱进程的ID。

3.一种为插件运行创建沙箱环境的装置，设于计算设备中，包括：

创建模块，用于创建沙箱环境，将针对每个插件的本地目录映射到所述沙箱环境中，将宿主机的设备管理目录映射到所述沙箱环境中；

资源限制模块，用于对不同沙箱环境增加不同的资源限制；

加载模块，用于加载插件进程管理；

接收模块，用于接收前端传送的消息，所述消息包含插件的ID、插件的版本，并传递给所述插件进程管理；

插件加载模块，用于通过所述插件进程管理加载对应的插件，其中在一个沙箱环境中仅加载一个主插件及所述主插件依赖的从插件；

插件服务创建模块，用于创建插件服务，由创建的插件服务调用所述创建模块、资源限制模块、加载模块、接收模块和插件加载模块；

置空模块，用于对所述沙箱环境进行置空处理，以清空所述插件服务存留在所述沙箱环境中的初始配置信息；

通信模块，用于建立与所述插件进程管理通信的通信端口，接收加载的插件通过所述插件进程管理进行的注册，获取相应插件的实例链接。

4.如权利要求3所述的为插件运行创建沙箱环境的装置，其中，所述通信模块接收沙箱进程的ID以用于管理，其中每运行一个插件进程即产生一个沙箱进程的ID。

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

至少一个处理器和存储有程序指令的存储器；

当所述程序指令被所述处理器读取并执行时，使得所述计算设备执行如权利要求1或2所述的为插件运行创建沙箱环境的方法。

6.一种存储有程序指令的可读存储介质，当所述程序指令被计算设备读取并执行时，使得所述计算设备执行如权利要求1或2所述的为插件运行创建沙箱环境的方法。

Images