白名单访问控制 — 未授权 App 完全看不到 su

设计理念

传统 root 方案（包括 Magisk）是默认开放、按需限制的模型——su 守护进程默认对所有 App 开放，只有明确拒绝的才拦截。APatch 则反过来：默认隐藏、按需授权——root 对所有 App 来说都是不存在的，只有管理器里被明确加进白名单的 App 才能获取 root 权限。

为什么更安全

传统方案的风险：

• su 守护进程是 root 权限的进程，任何能绕过授权检查的恶意 App 都能拿到 root
• su 二进制、magisk 属性等痕迹对所有 App 可见，root 检测代码可以轻松识别
• SafetyNet 等安全机制能检测到"这个设备有 root"

APatch 的方案：

• root 能力藏在内核的 SuperCall 里，对未授权的 App 完全不可见（密钥错误时静默返回）
• 任何外部检测都看不到 su 守护进程、su 二进制、magisk 属性这些"标记"
• 未授权 App 甚至不知道自己在一个 root 过的设备上

授权流程

当一个新 App 第一次尝试获取 root 权限时：

1. App 调用 syscall(SUPERCALL, ROOT_THREAD, ...)
2. 内核收到请求，检查 SuperKey
3. 密钥正确 → 但内核还要检查这个 App 的包名是否在白名单里
4. 白名单里没有 → 返回一个"需要授权"的信号给内核
5. 内核通过某种机制（发送通知、广播等）让用户知道有新 App 请求 root 授权
6. 用户打开 APatch 管理器，在权限管理页面找到这个 App，点"允许"
7. 下次再请求时，白名单有了，直接放行

白名单存储位置

授权信息保存在 /data/adb/ap/package_config 文件里。

授权的撤销

随时可以在管理器里把某个 App 的授权关掉：

1. 打开 APatch 管理器
2. 进入权限管理页面（不同版本可能叫"权限管理"或类似名称）
3. 找到要撤销的 App，点击
4. 选择"拒绝"或"撤销授权"

撤销后该 App 再请求 root 会被静默拒绝。

重置所有授权

如果遇到奇怪的授权问题（App 重启后自动获得/丢失 root 权限——这个 bug 据说已修复），可以重置整个授权配置：

# 用任何 root 终端执行
rm -rf /data/adb/ap/package_config

执行后重启设备，所有 App 的授权状态清零，需要重新逐个授权。

关于 shell 授权

有一个常见坑：不要给 shell 授权 root 权限。

很多用户习惯了 Magisk 里给 shell 授权，但在 APatch 里，给 shell 授权 root 后可能导致其他模块安装时报 os error 2/5/22 这类错误。这是因为 shell 被 root 后，它的 SELinux 上下文会影响其他进程的文件操作。解决方案：在权限管理里取消 shell 的 root 授权，重启设备。