HiShell：关在“笼子”里的终端

与 Android 类似，OpenHarmony 系统也实现了应用沙箱机制。HarmonyOS 继承了 OpenHarmony 的应用框架，因此同样继承了这个机制。

在 OpenHarmony 系统上，每一个 APP 都是跑在一个独立的应用沙箱中。应用沙箱通过 mnt-namespace 和 pid-namespace 等机制实现，每个应用相当于一个独立的 Docker 容器，不同应用无法互相访问对方的私有文件。

当我们在鸿蒙 PC 上打开 HiShell 进入终端，我们实际上是处于 HiShell 的应用沙箱内部。当我们在 HiShell 里面执行命令行程序的时候，我们的命令行程序相当于是跑在一个名为 HiShell 的 Docker 容器中。

该场景下的进程派生关系如下：

1号进程 -> appspawn -> com.huawei.hmos.hishell -> zsh

appspawn 作为 OpenHarmony 的应用孵化器，在此处充当了隔离边界。它在派生子进程时注入了命名空间（Namespace）属性，基于 Linux 进程的继承特性，后续派生的所有子进程将天然受限于该沙箱环境。

应用沙箱的“坑”

这个应用沙箱机制有非常多的安全管控措施，我们做命令行程序需要关注的主要有这些：

1. 挂载点隔离。应用沙箱里面的 /bin、/lib 等目录都是通过挂载点挂进来的，除用户家目录以外大多都是只读挂载。
2. DAC 机制的用法与常规的 UNIX-like 系统有差异。在应用沙箱中，每个用户都有自己独立的用户 id，我们在不同应用中（例如 HiShell 与 CodeArts IDE）所查询到的用户 id 是不一样的。
3. 大面积使用了 SELinux。在沙箱内，各种 IO 操作、进程操作等行为都会受 SELinux 管控。另外，虽然这个 SELinux 是 Linux 内核里面的能力，但鸿蒙内核同样把这个能力也做了实现。在 HarmonyOS 上，他们将其称为 SEHarmony。
4. 启用了 seccomp 机制。如果你调用了一些不在 seccomp 白名单内的 syscall，你将会被 seccomp 给拦截下来。

这些安全管控措施会导致这些常见问题：

• mount、chroot、chown、getpwuid、 setfsuid 等 libc 接口不能正常工作。
• 一些调试工具无法正常工作。
• 用户身份与文件属主不匹配导致部分程序无法正常工作。
• 在沙箱里面访问不到未挂载的系统目录，也无法往已挂载的系统目录写入任何东西。
• 沙箱内未提供完整的 FHS 目录，也不允许用户自行创建，如果开源软件对 /tmp 等 FHS 目录有强依赖，它将无法正常工作。
• 无法实现真正的 sudo 命令。我们在 HiShell 中使用的那个 sudo 命令只是个残缺版的 sudo，并不能让我们真正提权成 root 用户。

hdc shell：跳出沙箱，但不代表无敌

以上讨论的是应用沙箱内的受限情况。什么情况下我们可以不在应用沙箱里面呢？

应用沙箱，顾名思义就是针对应用的沙箱。只要我们不在应用里面，那自然也就不在应用沙箱里面了。

例如：通过 hdc shell 接入的调试终端，它就不在应用沙箱中。

该场景下的进程派生关系如下：

1号进程 -> hdcd -> sh

此时，sh 进程由系统调试服务 hdcd 直接拉起。由于 hdcd 运行在宿主机命名空间内，它派生的 sh 同样处于非沙箱环境。

但需要明确的是，“脱离沙箱”并不等同于“获得最高权限”。想在鸿蒙 PC 上实现“为所欲为”，需要同时满足两个独立维度：

1. 空间维度（非沙箱）：能看到真实的物理根文件系统。
2. 权限维度（root 身份）：拥有不受限的 UID 0 和系统 Capabilities。

只有当这两个条件同时满足时，开发者才能绕过所有管控，执行不受限的底层调试。

在鸿蒙 PC 上，出于安全考虑，hdcd 派生的 sh 虽已脱离应用沙箱，但其身份被限制为低权限的 shell 用户。此时，你虽然能看到完整的系统目录，但依然无法执行 mount、修改系统配置或读写受保护的设备节点。

如果你手里有一台搭载社区版 OpenHarmony 的设备（例如鸿蒙开发板），情况就截然不同了。这类设备主要面向底层驱动和内核开发者，系统镜像通常默认开启了完整的调试特权。在这种环境下，hdcd 直接以 root 身份运行，拉起的 sh 既在沙箱外，又具备 root 权限。这种 “非沙箱 + root” 的状态，才是真正意义上的完全控制。