RK3588 Android 12设备权限修改：从chmod到SELinux-北京尧图网络

1. 场景先行你遇到的设备权限问题到底属于哪一类经常有做 RK3588 项目的朋友问我类似的问题我在 Android 12 上访问 /dev/ttyS4 报 permission denied设备权限怎么改说实话这个问题没法用一句chmod 777打发。RK3588 是当下很多 AIOT 设备和开发板在用的平台Android 12 的权限管理又比老版本严格不少如果你一上来就闷头改文件权限很容易陷入改了没用、重启失效、才改完又被审计拦下来的连环坑。我自己就在一块 RK3588 板子上栽过跟头。当时要调试一个串口外设应用层通过 JNI 去open(/dev/ttyS4, O_RDWR)结果返回失败。第一反应是看节点权限adb shell ls -l /dev/ttyS4输出是crw-rw---- root root。应用跑在普通 app 的 uid 下确实没有读写资格。于是我想当然地执行了chmod 666 /dev/ttyS4功能立刻通了但重启后权限全部还原。接着我又试图把这条命令固化到 init.rc 里编译烧录后发现还是不行——因为 Android 12 默认开着 SELinux 的 enforcing 模式文件权限放开了安全策略照样把你拦在门外。那次之后我把整个权限链路从头到尾捋了一遍。先说清楚一个概念在 RK3588 Android 12 系统里设备权限从来不是单一的一件事而是由三层共同决定。设备节点的 mode 和属主比如/dev/ttyS4是 0660 还是 0666属主是root:root还是system:shell。这是最直观的一层ls -l就能看到。设备节点的创建逻辑节点不是天生存在的是 init/ueventd 收到内核事件后创建出来的创建时的权限由配置文件决定。临时手动chmod一旦碰到节点重建就会被覆盖。SELinux 安全策略即便 chmod 给了读写权限SELinux 在 enforcing 模式下仍会通过类型规则决定某个进程能不能访问该节点。这是最隐蔽、也最容易被忽略的一层。这三层分别对应不同的改法。先分清你卡在哪一层再决定动哪个文件。1.1 一段典型的 RK3588 串口调试经历我接手那个项目的时候设备是一个基于 RK3588 的工控盒子系统版本是 Android 12底板上引出了几路串口和 I2C。需求很简单系统里安装一个控制类 App通过串口跟外设通信。App 的 native 层代码很直白int fd open(/dev/ttyS4, O_RDWR | O_NOCTTY); if (fd 0) { // 报错 }编译、安装、运行结果就是打不开。第一层我确认过节点存在权限是crw-rw----属主 root。App 不属于 root不属于 system 组自然没权限。当时我的第一个动作是临时验证用了最快但最粗暴的方式adb root adb shell chmod 666 /dev/ttyS4App 再跑通了。可这只能证明改设备节点权限确实能解决问题离真正交付还差得远。重启后节点权限大概率被 ueventd 按配置重置同时系统审计日志里也留下了一堆 SELinux 的 denied 记录。这一步其实很有价值它帮我确认了问题确实出在权限层而不是驱动、管脚复用或者串口配置。后面要做的是把这种手工生效变成系统启动就是正确的状态。1.2 三类最常见的权限诉求在实际 RK3588 项目里我见过的大多数修改设备权限需求可以分成三类第一类是应用层访问外设节点。比如 App 要操作串口、GPIO、I2C 或者 SPI 设备典型表现就是open()返回Permission denied。这类问题的解决路径最完整需要同时处理节点权限和 SELinux 策略。第二类是系统服务或开机脚本需要访问某些节点。比如某个 vendor 进程要在 boot 阶段读写一个传感器节点或者 init.rc 里想 cp 一个文件到 /data 目录但权限不足。这类问题通常涉及 init.rc / ueventd.rc 里的chmod、chown配置以及对应 service 的 SELinux 域。第三类是纯开发调试期的临门一脚。只是为了在开发阶段快速验证硬件通路想在 userdebug 版本上临时放权不考虑交付。对这种需求有时候一条setenforce 0加chmod 666就够用了但千万不要把这种做法直接搬进量产固件。分清这些后面的操作才有针对性。2. 权限体系解剖RK3588 上 Android 12 的三道门我在接触 RK3588 的 Android 12 之前对权限的理解基本停留在chmod和chown。但在实际项目中你会发现这两条命令只是表象真正决定你有没有权限访问一个设备节点的是下面这三道叠加在一起的门。2.1 第一道门/dev 节点 mode 与属主所有设备节点在 Linux 里本质都是特殊文件有自己的一套属主、属组和权限位。RK3588 板子上常见的/dev/ttyS0、/dev/gpiochip0、/dev/i2c-1、/dev/spidev2.0都是这样。这个 mode 是谁决定的内核里的 devtmpfs 会在设备注册时自动生成节点但具体权限通常由 Android 的 ueventd 根据配置文件在创建节点时指定。举个例子一条典型的 ueventd.rc 配置是/dev/ttyS4 0660 root system意思是这个节点属主是 root属组是 system权限是crw-rw----。如果 App 进程既不是 root也不属于 system 组那就没有读写权限。这里有个绝大多数人都会忽略的细节你手动执行chmod改掉的权限只对当前存在的那个节点有效。一旦设备节点被内核事件重新触发创建比如串口重新 probe、USB 设备重新插拔、系统重启权限又会回到配置文件里定义的样子。所以手工chmod从来不是交付方案只是排查手段。2.2 第二道门init/ueventd 的权限管理逻辑Android 启动过程中init 进程会启动一个 ueventd 的子进程。ueventd 的作用是监听内核的 uevent收到事件后负责在 /dev 下创建对应的节点、设置软链接并按照配置文件给节点赋权限。ueventd 读的配置主要是各个分区里的ueventd.rc文件。RK3588 的 SDK 里设备的 ueventd.rc 通常放在设备目录下比如类似device/.../rk3588/ueventd.rc这样的地方同目录下还可能存在按模块拆分的子文件。不同平台的习惯不太一样但逻辑是统一的找对 ueventd.rc在里面加一行节点权限规则系统每次创建设备节点时都会按这个规则来。不过 ueventd.rc 也有管不到的地方。它主要在设备节点创建时生效而 sysfs 里许多属性文件、debugfs 下的调试接口、还有一些用 misc driver 注册的逻辑节点并不一定走标准的 devtmpfs 流程。这时候更多会借助 init.rc 里的启动阶段命令。init.rc 是 init 进程的主脚本支持在on boot、on property:xxx等触发点执行chmod、chown、mkdir等命令。比如on boot chmod 0666 /sys/class/.../attr chown system system /sys/class/.../attr这种方式灵活但有执行时机的问题如果触发时节点还没创建命令就会静默失败。所以工程上我一般优先用 ueventd.rc 管 /dev 节点用 init.rc 补 sysfs 和特殊路径。2.3 第三道门SELinux 的 avc 拦截机制这是 RK3588 Android 12 里最容易出问题、也最让新手困惑的一层。SELinux 会给每个进程打一个安全上下文标签比如u:r:untrusted_app:s0给每个文件/设备节点也打一个标签比如u:object_r:tty_device:s0。进程访问节点时系统不仅在文件权限层校验 uid/gid还要在安全策略层判断这个进程域有没有权访问那个对象的类型。判断的依据是 policy由一堆 .te 文件在编译时生成。一旦策略里没有对应的 allow 规则访问就会被拒内核在 dmesg 里打印一条类似这样的日志avc: denied { open } for pid1234 commxxx path/dev/ttyS4 devtmpfs scontextu:r:untrusted_app:s0 tcontextu:object_r:tty_device:s0 tclasschr_file注意即使你把 /dev/ttyS4 的 mode 改成了 0666App 的 uid/gid 已经放行只要 SELinux 还在 enforcing 模式这条 avc 拒绝依然会把 open 拦下来。我见过太多人在这层上面两眼一抹黑文件权限明明都对了App 还是打不开设备最后查下来是 SELinux 的策略没放行。2.4 Android 12 对 SELinux 的强化点Android 12 相比 Android 9/10最大的感觉是不再给你那么多偷懒空间。一是 neverallow 规则更多以前经常用的某些宽泛放行写法在编译阶段就直接被拒绝二是 vendor 和 system 的分离更彻底修改 system 镜像还牵涉启动校验的问题三是 treble 化之后权限策略被拆成 system 和 vendor 多段单独改一边不一定有用。在 RK3588 的 userdebug 版本上你可以通过adb root后setenforce 0临时关掉 SELinux 来做硬件调试但量产固件基本都在 enforcing 模式下运行。开发阶段能用 permissive 快速验证功能交付阶段如果还是 permissive上线后大概率会在安全审计上出问题而且平台的 neverallow 链路也可能禁止你整体修改为 permissive。正确做法是临时关掉只是确认问题最终一定要把精确的 allow 规则写进 policy。3. 权限修改实操从临时验证到固化烧录现在说具体怎么做。我通常会按先临时验证再固化配置最后补 SELinux 策略的顺序推进每一步都有它存在的理由。3.1 第一步adb shell 临时验证功能链路拿到一个报权限问题的 RK3588 设备我推荐先不要急着改代码。先确认整条硬件链路是不是通的。具体操作adb root adb wait-for-device adb shell chmod 666 /dev/ttyS4 adb shell chown system:system /dev/ttyS4然后跑你的 App 再试一次。如果通了说明设备节点权限确实是最主要的瓶颈。如果还不行那问题可能就不在权限上而是在驱动注册、设备树配置、管脚复用或者 open 方式上比如你 open 的是错误节点或者设备根本没 probe。这一步的价值是快速把权限问题和非权限问题切分开。我习惯把这一步的结果记录在案后面所有固化操作都以这个基线为准。还有个细节adb root只存在于 userdebug/eng 版本release 版本没有这个入口。如果你手里的机器是 release 固件开发期最好先让编译版本切到 userdebug否则后面的大多数排查手段都用不上。3.2 固化方式一ueventd.rc 指定节点属性临时验证通过后第一件要做的事就是把权限写进 ueventd.rc让系统每次创建设备节点时都按你的规则来。以 RK3588 平台的 SDK 为例设备相关的 ueventd.rc 一般位于设备板级目录下比如类似device/.../rk3588/ueventd.rc的路径也可能有按产品型号拆分的ueventd.产品.rc。找到内容后在文件里增加一行/dev/ttyS4 0666 system system这行的格式是节点路径、mode、属主、属组。注意这里的路径要跟设备实际上报的 devname 一致不能用软链接路径因为 ueventd 先创建设备文件之后才处理 symlink。如果你不确定该改哪个文件可以先用下面命令看 ueventd 实际加载了哪些配置adb shell ls -l /dev/block/by-name/ # 不重要 # 更直接的是 adb shell ps -A | grep ueventd实际上更实用的方法是直接查看当前节点的权限来源。对已经存在的节点比较难反查它来自哪个配置文件最稳妥的做法是全源码搜索你要修改的节点路径看它在哪个 ueventd.rc 或 init.rc 中出现过。如果整个 SDK 里都搜不到说明节点走的是内核默认的 devtmpfs 权限通常 0600 root root这时新增一行 ueventd.rc 规则就是正确解法。3.3 固化方式二init.rc 里补 chmod/chownueventd.rc 适合管 /dev 下标准设备节点但有些文件它管不了典型包括 sysfs 导出的属性文件比如背光亮度、GPIO 的 direction/value以及部分 debugfs 节点。这些文件往往在系统启动过程中由内核动态创建权限默认是0444或者更严格。需要放开的时候我会在 init.rc 里加启动命令。常见的写法是这样on boot chmod 0666 /sys/class/gpio/gpiochip0/device/direction chown system system /sys/class/gpio/gpiochip0/device/direction或者针对需要等待设备真正 ready 的场景用属性触发on property:sys.boot_completed1 chmod 0666 /sys/class/.../attr这里要注意两条第一init.rc 里的脚本命令在目标文件不存在时会直接返回失败不会报错也不会重试所以如果你发现节点确实存在但命令没生效优先怀疑执行时机太早第二chmod/chown 的对象路径如果带有通配符语法和匹配规则跟 shell 里不完全一样尽量写全路径减少意外。3.4 固化方式三为 App/服务补充 SELinux 规则这一步才是真正解决为什么 chmod 后 App 还是访问不了的关键。SELinux 的规则写在 .te 文件里编译时被打进 sepolicy。RK3588 Android 12 的 SDK 里sepolicy 相关代码分布在 system/sepolicy、vendor 相关目录以及设备板级目录下。常见需要改的地方有几类第一类给 App 访问设备开绿灯。理论上 Android 不允许普通 App 直接访问任意设备节点很多产品会把访问逻辑封装在一个特权服务里App 通过服务间接操作。如果你的产品确实需要让某个 App 直接访问串口一种相对可控的做法是把这个 App 指定为 system_app 或 privileged_app然后在对应的 te 文件里追加 allow 规则。例如在untrusted_app.te里allow untrusted_app tty_device:chr_file rw_file_perms;但这么做有风险。Android 12 的 neverallow 规则经常禁止 untrusted_app 直接访问这类节点编译时就会报错。更常见的做法是给特定场景单独定义一个类型或者使用vendor_file域的服务去处理。不要为了省事对所有域通配放行平台的 neverallow 会教你做人。第二类给系统服务或 vendor 进程放行。操作对象通常是你在 init.rc 里启动的某个自定义服务你需要确认它的 domain 以及它访问节点的类型。比如你的服务域是myservice节点上下文是tty_device那么allow myservice tty_device:chr_file rw_file_perms;第三类修改节点的 SELinux 标签。这一步经常被忽略。即使你写了 allow 规则如果节点的安全上下文不是你预想的类型规则就不匹配。RK3588 上有file_contexts文件负责给 /dev 下的节点打标签。你可以给特定节点指定一个单独类型比如/dev/ttyS4 u:object_r:tty_device:s0如果节点没匹配到 file_contexts 里的规则它会被打上默认标签可能是device也可能是tmpfs这样你的 allow 规则可能就完全落空了。4. 编译烧录与验证的完整闭环权限改完不是说存个文件就完事。RK3588 Android 12 的分区结构决定了你改了不同位置要编译烧录的镜像完全不同。这一节我重点说说怎么把这些改动变成设备上真正生效的状态。4.1 哪些改动对应哪些分区与镜像我习惯先列一张表每次改完照着查修改的位置大致对应的镜像/分区说明device 板级目录下的 ueventd.rcvendor 相关分区 / vendor_boot节点权限配置属于 vendor 侧init.rc / init.xxx.rcboot / vendor_boot取决于具体平台的分区策略system/sepolicy 下公共策略boot 中的 sepolicy / system 分区改动 system 侧 policy 通常影响 boot 镜像设备板级目录下的 sepolicy 策略vendor 相关分区 / bootvendor 域的规则一般进 vendor_boot 或 bootfile_contextsboot / vendor标签文件影响节点安全上下文这个表格在不同 SDK 版本上会有细节差异但原则一致vendor 相关文件尽量打包进 vendor/vendor_bootsystem 相关文件打包进 system/boot。RK3588 平台因为 GKI 内核的引入boot 镜像里通常会带一版 sepolicyvendor_boot 里也带一段 vendor sepolicy两边编译时合并。你改了 vendor 侧的 .te 文件却没烧 vendor_boot现象就是我明明改了重启后还是 denied。具体到编译动作一般是先执行 SDK 提供的打包命令生成对应镜像。举例来说如果只改了设备目录下 ueventd.rc 和 vendor sepolicy我通常会编译并烧写 vendor_boot 和 vendor 镜像。改完没必要整包刷机烧对应分区能省很多时间但前提是你清楚自己改的内容落在哪个分区否则烧了等于没烧。4.2 权限生效后的自查命令与检查项烧录完成、系统重新起来之后我有一套固定的检查命令基本能覆盖上面说的三层门# 1. 看节点权限和属主 adb shell ls -l /dev/ttyS4 # 2. 看节点 SELinux 标签 adb shell ls -Z /dev/ttyS4 # 3. 看当前 SELinux 模式 adb shell getenforce # 4. 实时抓 avc 拒绝日志 adb shell dmesg | grep avc adb logcat -d | grep avc一个健康的最终状态应该是ls -l显示你预期的 mode 和属主ls -Z显示你在 file_contexts 里定义的标签getenforce是 Enforcingdmesg里没有新的 avc denied。如果节点权限对了、标签也对了App 依然报错再看一下 App 进程的 uid 和 domainadb shell ps -A -Z | grep 你的包名对应 App 的 domain 需要和你在 allow 规则里的 scontext 一致。如果 App 的 domain 是untrusted_app而你给priv_app写了规则那自然还是不行。4.3 一个完整的验证清单我把这些整理成一个清单方便项目里传阅确认/dev/ttyS4节点存在ls -l权限符合预期。确认ls -Z标签符合预期。确认getenforce为 Enforcing。App 重新打开设备看是否成功。dmesg和logcat中不再出现新的 avc denied。拔插相关设备或重启系统确认权限仍然正确。如果用 init.rc 命令改的 sysfs 属性确认触发时机准确节点出现后属性确实被改掉。这个清单最大的价值是防止开发机上是好的、量产机上就失效。比如你只在 userdebug 上验证过重启后没问题但量产固件是 user 版本、没有 adb root、SELinux 又是 enforcing情况就会完全不同。5. 排错实录我在这块板子上踩过的几个权限坑做 RK3588 几年下来权限问题的坑我基本都踩了一遍。下面这几个例子不是理论推演都是实际调试中反复遇到过的场景写出来供大家排错时对照。5.1 坑一改了 ueventd.rc 权限却不生效有一回我在一台 RK3588 设备上要放开/dev/ttyS1的权限在 ueventd.rc 里加了一行0666 root root编译烧录后一看节点权限还是老的crw-rw----。当时我一度怀疑是不是编译缓存问题后来发现是配置文件根本没被加载。原因很典型平台有多个 ueventd.rc系统实际加载的是根据硬件型号拼出来的ueventd.产品名.rc而不是我一直改的那个公共ueventd.rc。排查办法也很简单先看当前加载的配置文件路径。在 init 执行早期日志里会打印加载了哪些 ueventd 配置文件或者去源码里 grep 一下产品型号相关的 rc 文件。确定文件改对后再检查编译产物是否真的包含这个修改很多时候问题出在镜像没烧对分区而不是配置本身写错。5.2 坑二avc denied 反复出现明明 allow 规则写了这类问题最容易让人怀疑人生。你明明在某个 .te 文件里加了 allow 规则重新编译烧录后 dmesg 里却还在刷同样的 avc denied。我遇到过两个可能。第一个是 file_contexts 没配对。例如我允许某个进程访问tty_device类型但实际节点的 SELinux 标签是device因为文件上下文里那条/dev/ttyS4的规则没有生效节点落到了默认标签上。allow 规则写的是tty_device实际访问的是device两边对不上自然继续被拒。第二个是修改的 policy 没有打进对应的镜像分区。treble 化之后 vendor policy 和 system policy 分离你改了 system 侧的公共规则却只烧了 vendor 分区或者改了 vendor 侧规则只烧了 system 分区。它不会报错但行为就是规则不存在。遇到反复 avc denied先别急着加新规则而是把你改的文件落到了哪个分区这件事查清楚。5.3 坑三App 通过 JNI 访问串口还是失败有次一个合作方找到我说 RK3588 Android 12 上App 在 debug 状态怎么都正常一旦切到 user 版本就彻底打不开串口。我们远程查了两天最后发现是 App 的 SELinux domain 不同。debug 版的 App 是用包管理器安装的domain 是untrusted_app而合作方为了获取特权把 App 放进了系统的 priv-app 目录并且声明了 privileged 权限于是它的 domain 可能变成了priv_app。我们一开始只给untrusted_app写了 allow所以 privileged 模式下反而被拦。这类问题提醒我排查 avc 日志时一定要确认 scontext 和 tcontext 两侧分别是什么然后把规则写到对的那个 domain 上。用日志里的实际字符串写规则而不是靠猜。看到avc: denied { open }就以为加一条allow xxx tty_device:chr_file open就结束往往只是开始的一半。5.4 通用排查链路最后我把排查权限问题的链路整理成一个固定套路基本能覆盖 80% 以上的场景第一步确认硬件链路。节点是否存在驱动有没有 probedmesg | grep ttyS4有没有异常。硬件没起来就改权限纯属缘木求鱼。第二步确认文件权限层。ls -l看 mode 和属主。不确定的话在 userdebug 上 adb root 后手动chmod 666测试。通了说明问题在文件权限不通则往驱动、设备树方向排查。第三步确认 SELinux 层。getenforce看当前模式如果 enforcing抓dmesg | grep avc看有没有和你的进程/节点相关的拒绝记录。有 denied 就按 scontext、tcontext、tclass 精确补规则。第四步固化修改。把临时命令转成 ueventd.rc / init.rc / .te 文件确认落在哪个分区重新编译烧录。第五步重启复验。重点检查两层权限是否还在avc 是否继续刷。如果重启后恢复到旧权限说明 ueventd.rc 没有被正确加载或没被打进镜像。这套链路我从 RK3588 一直用到其他平台总体思路都是通用的差别只在具体文件路径和分区名。6. 最后再分享两个小技巧写到这儿该讲的链路基本都覆盖了最后分享两个我在实际项目里觉得很重要的小习惯。第一个习惯是所有权限修改尽量收敛在 vendor 分区侧。RK3588 Android 12 的项目里vendor 侧改动比 system 侧改动好维护得多而且不依赖全局镜像重刷。比如设备和产品相关的 ueventd.rc、vendor 域的 sepolicy都优先放到设备板级目录下不要动 system/sepolicy 公共部分。这样不同产品型号之间的权限配置隔离得更干净升级系统版本时也少一些冲突。第二个习惯是把每一个权限改动都记录清楚为什么要放和放给谁。权限问题最怕的就是顺手开个权限最后根本不知道哪个域因为哪条需求被放开。项目里我习惯在 commit message 里写明白节点路径、目标 domain、触发场景、对应的应用需求单号。等哪天出安全审计或者 after 版本升级这份记录能帮你省下好几个通宵。RK3588 Android 12 的设备权限修改说难其实不难本质就是厘清设备节点权限、初始化配置、SELinux 策略这条链路按顺序一步步来。真正做到位的标志不是我现在能访问了而是重启之后、换一台机器之后、从 userdebug 换成 user 之后依然能访问。祝各位调试顺利少遇几个坑。

RK3588 Android 12设备权限修改：从chmod到SELinux

相关推荐

语音识别入门实战：从原理到搭建可运行的转写系统

可解释性AI落地指南：LIME与SHAP工具选型及避坑实践

欧拉公式：数学中最优雅的常数统一之美

更多资讯

A-29P宽压供电架构：4V~16.5V电压域的功耗与权衡A-59F是一款重新设计并全面升级的多功能语音处理模组，集成了本地扩音防啸叫、AI智能降噪、全双工回音消除以及双麦波束成形四大核心功能。该模组

【合规领域】【信息科学与工程学】计算机科学与自动化——第五百篇国产化/XC解决方案第二篇海光CPU/DCU芯片适配02

从零复现tinyllama-colorist-lora：基于TinyLlama-1.1B-Chat的LoRA微调实操指南

tf_mixnet_s.in1k项目全景概览：4.1M参数轻量级图像分类模型（MixNet架构）到底强在哪？

戴森球计划FactoryBluePrints：工厂蓝图速通指南

4-1-Computer Class Built-in Variables-sysBootTime

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？