Root 权限到底是什么：从 su 到 Magisk

折腾安卓设备，“root”这个词几乎绕不开，但很多人其实说不清它具体指什么。这篇从安卓的权限模型讲起，把 root 到底是什么、怎么拿到、现在主流方案 Magisk 又做了什么不一样的事，理一遍。

安卓的权限模型是怎么隔离 App 的

安卓系统的内核是 Linux,继承了 Linux 那套基于用户和用户组的权限体系。每装一个 App,系统都会给它分配一个独立的 UID(用户 ID),这个 App 之后跑起来的所有进程都在这个 UID 下执行。文件系统上的权限检查(也就是常说的 DAC,自主访问控制)会根据这个 UID 判断这个进程能不能读写某个文件、能不能访问某个资源。

这套机制天然把 App 之间隔离开了——A App 默认读不到 B App 私有目录下的数据,因为它们的 UID 不一样。而 UID 为 0 的用户,也就是 root,在这套 DAC 体系里是特殊的:它可以绕过几乎所有基于 UID 的权限检查,读写任何文件、修改任何系统配置。手机出厂时,普通 App 和用户都没有拿到 UID 0 的能力,这就是通常说的”没有 root 权限”。

早期方案:一个叫 su 的二进制文件

传统 Linux 系统里,普通用户想临时获得 root 权限,标准做法是执行 su 命令,输入密码完成身份验证后切换到 root 身份。安卓上的早期 root 方案基本照搬了这个思路:把一个 su 可执行文件塞进系统分区(通常是 /system/bin 或 /system/xbin),再配一个图形化的管理 App(早期比较有名的是 SuperSU)。

当某个 App 需要 root 权限时,它会在后台调用这个 su 二进制文件发起请求,管理 App 弹出授权弹窗让用户确认,用户同意后,这次请求对应的进程就会被提权到 UID 0,之后就能执行原本受限的操作。这套方案的核心动作,是往系统分区里塞文件、改系统权限——这也是它后来暴露出问题的地方。

Magisk 换了一个思路

Magisk 现在是安卓 root 圈事实上的主流方案,但它解决问题的方式和早期的 su 方案不太一样,通常被称为”Systemless(无系统分区修改)“root。

具体来说,Magisk 不直接往 /system 分区里写文件,而是通过重新打包 boot 镜像(也就是常说的”刷入 Magisk 的 patched boot.img”)完成注入。设备启动到很早的阶段时,Magisk 会通过 overlayfs 这类联合文件系统技术,在不改动原始系统分区内容的前提下,把 su 环境和各种模块”叠加”到系统的可见文件结构上——系统分区本身在存储介质上始终保持出厂时的原始状态,改动只发生在运行时的挂载层面。

Zygisk 和隐藏 root 状态

除了注入 su 环境,Magisk 还提供了 Zygisk 这个功能,可以在 App 进程启动时对其运行环境做进一步的干预,配合 DenyList(隐藏列表)机制,可以让指定的 App 完全感知不到设备已经被 root、也感知不到 Magisk 本身的存在。这也是为什么现在很多人愿意在日常使用的主力机上刷 Magisk——可以做到对大部分敏感 App”选择性隐身”,不影响正常使用银行、支付类应用。

小结

Root 本质上就是 Linux 权限体系里的 UID 0,能绕过系统层面的访问限制。早期方案靠往系统分区塞 su 文件实现,简单直接,但容易被检测、也不好维护;Magisk 换成了运行时挂载叠加的思路,系统分区本身保持原样,兼容性和隐蔽性都更好,这也是它能成为现在主流方案的原因。理解了这层原理,再去看”刷 Magisk”这几个字,大概就知道设备实际发生了什么。