Fuchsia沙盒

沙盒

本文档描述Fuchsia系统中的沙盒如何运作.

空进程一无所有

在Fuchsia系统中，新创建的进程一无所有。新进程不能访问任何内核对象，不能分配内存，甚至不能执行代码。理所当然的，这样的进程没有什么用处，这就是为什么在创建进程时我们通常为其附带初始资源和能力的原因。

更通常的情况是，进程与附带的资源一起开始执行一些代码，这些资源包括初始堆栈，命令行参数，环境变量和初始句柄集合。最重要的初始句柄之一是PA_VMAR_ROOT，进程可使用其来映射额外的内存到自身地址空间中。

命名空间是通往世界的大门

给予进程的一些初始句柄为目录，进程将其挂载到自身_命名空间_中. 这些句柄可使进程发现系统中的其它进程，并通过句柄与其通信，包括文件系统和其它服务等。详细信息请见 Namespaces .

给予进程的命名空间在相当大的程度上决定了进程反过来影响系统的程度。所以，配置进程运行的沙盒相当于配置进程的命名空间。

包命名空间

由包中运行的组件component有权限访问/pkg，其是一个包含组件的包的只读视图。要在运行时使用这些资源，进程可利用/pkg命名空间。例如，root_presenter 可使用决定路径/pkg/data/cursor32.png 来访问 cursor32.png。

服务

作为组件components的进程将在自身命名空间中接收到/svc目录。通过/svc可用的服务是组件环境environment所提供的服务的一个子集。此子集由位于组件的manifest file中的 sandbox.services 所定义的白名单决定.

典型的组件将与/svc中的一些服务交互，以便在系统中扮演有一定用处的角色。例如，组件想要加载其它组件就需要借助fuchsia.sys.Launcher服务。

非组件类的进程也有可能有/svc目录。这类进程的创建者有权决定给其决定提供什么样的/svc目录。

注意: 在过去，没有针对服务型沙盒的机制，组件可接收到其环境中的所有服务。已经存在的具有deprecated-all-services特性的组件可以不受限的接收所有的服务，但是这些最终将被移除。请不要在新组件上使用 deprecated-all-services特性。

配置额外命名空间

如果进程需要访问额外的资源（如，设备驱动），可通过在其包文件Component Manifest的sandbox属性中添加额外名称，来请求访问权限。例如，以下的meta/sandbox文件中请求对输入设备驱动的直接访问权限。

{
    "dev": [ "class/input" ]
}

在当前的实现中，AppMgr对此类请求进行授权，但是，随着系统的进化由可能会改变。

构建包

要构建包，需要使用gn中的package()宏，gn定义于文件//build/package.gni. 参见该文档中对package()宏关于包含资源的详细描述。

例如，参见[https://fuchsia.googlesource.com/garnet/+/master/packages/prod/fortune] 和 [https://fuchsia.googlesource.com/garnet/+/master/bin/fortune/BUILD.gn].