Android开机启动脚本权限问题全解，SELinux不再难

Android开机启动脚本权限问题全解，SELinux不再难

1. 引言：开机启动脚本的工程价值与挑战

在Android系统开发中，实现自定义服务或功能的开机自动执行是一项常见需求。无论是设备初始化配置、硬件检测、日志收集还是第三方守护进程的启动，开机启动脚本都扮演着关键角色。

然而，在实际落地过程中，开发者常常遇到“脚本无法执行”、“Permission denied”、“avc denied”等错误。这些问题大多源于对SELinux（Security-Enhanced Linux）机制理解不足和init进程上下文权限配置不当。

本文将围绕一个完整的实践案例——“测试开机启动脚本”，系统性地解析从脚本编写到SELinux权限配置的全流程，帮助你彻底掌握Android平台下开机脚本的权限管理逻辑，让SELinux不再成为拦路虎。

2. 开机启动脚本的基本流程与核心组件

2.1 整体执行流程概览

Android系统的启动由init进程主导，其通过解析.rc文件来启动服务和执行动作。要实现脚本开机运行，需完成以下四个关键步骤：

• 编写可执行的Shell脚本
• 将脚本部署至系统镜像指定路径
• 在.rc文件中注册为service
• 配置SELinux策略以允许执行

这四个环节环环相扣，任一环节出错都会导致脚本无法正常运行。

2.2 init.rc中的服务生命周期控制

在Android中，init进程依据init.rc及其包含的其他.rc文件（如init.<device>.rc）来管理系统服务。每个服务都有明确的状态属性，例如：

class main # 属于main类的服务，随系统启动而启动 user root # 指定运行用户身份 group root # 指定所属组 oneshot # 执行一次即退出，适合脚本任务 disabled # 默认不启动，需显式触发 seclabel # SELinux安全标签，决定其访问权限

其中，seclabel是解决权限问题的核心所在。

3. 实践应用：从零实现一个开机启动脚本

3.1 编写Shell脚本并验证可执行性

首先创建脚本文件init.test.sh，内容如下：

#!/system/bin/sh # # 测试开机启动脚本 # # 设置一个属性用于验证脚本是否执行成功 setprop test.boot.script.executed 1 # 可选：输出日志便于调试 log -t "InitScript" -p i "Test boot script executed successfully"

重要提示：脚本首行必须使用/system/bin/sh，不能使用/bin/sh。Android系统中shell解释器位于/system/bin/目录下，路径错误会导致脚本无法解析。

✅ 调试建议：

在烧写镜像前，可先手动将脚本推送到设备进行测试：

adb push init.test.sh /data/local/tmp/ adb shell chmod +x /data/local/tmp/init.test.sh adb shell sh /data/local/tmp/init.test.sh adb shell getprop test.boot.script.executed

确保能正确设置属性后，再进入下一步。

3.2 部署脚本到系统镜像

将脚本放入系统镜像的可执行目录，推荐使用/system/bin/或/vendor/bin/（根据平台规范选择）。假设我们将其放在/system/bin/init.test.sh。

在构建系统中添加该文件的拷贝规则（以Android.mk为例）：

# Android.mk LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := init.test.sh LOCAL_SRC_FILES := $(LOCAL_MODULE) LOCAL_MODULE_CLASS := ETC LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/../bin LOCAL_MODULE_TAGS := optional include $(BUILD_PREBUILT)

这样在编译时，脚本会被打包进system.img。

3.3 在.init.rc中注册服务

新建或修改设备专属的.rc文件，如init.device.rc，添加以下服务定义：

service test_boot_script /system/bin/init.test.sh class main user root group root oneshot disabled seclabel u:object_r:test_service_exec:s0

说明：

• disabled表示默认不启动，便于调试阶段手动启用。
• 启动方式：可通过setprop ctl.start test_boot_script手动触发。
• 若希望开机自动运行，移除disabled即可。

3.4 SELinux策略配置详解

这是最容易出错的部分。即使关闭了SELinux（enforcing=0），仍需声明类型转换规则，否则init无法加载服务。

(1) 创建TE策略文件

新建test_service.te文件，内容如下：

# 定义域类型（domain） type test_service, coredomain; # 定义可执行文件类型 type test_service_exec, exec_type, file_type; # 允许init域转换到test_service域 init_daemon_domain(test_service) # 可选：调试期间放开所有限制 # permissive test_service;

(2) 关联文件上下文

编辑file_contexts文件（通常位于device/<company>/<platform>/sepolicy/file_contexts）：

/system/bin/init\.test\.sh u:object_r:test_service_exec:s0

此条目告诉SELinux：当访问/system/bin/init.test.sh时，应赋予其test_service_exec类型。

(3) 策略文件集成

将test_service.te放入合适的SELinux策略目录，例如：

• 高通平台：device/qcom/sepolicy/generic/
• MTK平台：device/mediatek/sepolicy/basic/non_plat/

确保构建系统能识别并编译该策略模块。

4. 常见问题排查与解决方案

4.1 脚本未执行？检查init日志

使用dmesg | grep init查看init进程是否尝试启动服务：

dmesg | grep test_boot_script

若无输出，说明服务未被加载，可能原因包括：

• .rc文件未被import导入
• 语法错误导致解析失败
• 文件路径拼写错误

4.2 出现“Permission denied”？

多数情况下是SELinux阻止了执行。查看内核日志：

dmesg | grep avc # 或 logcat | grep avc

典型输出：

avc: denied { execute } for name="init.test.sh" dev="sdaXX" ino=XXXX scontext=u:r:init:s0 tcontext=u:object_r:system_file:s0 tclass=file

含义：init域试图执行一个标记为system_file类型的文件，但未授权。

解决方案：

• 确认file_contexts中路径匹配正确（注意转义.）
• 确保.te文件中定义了exec_type并关联了init_daemon_domain

4.3 setprop失败？属性SELinux权限缺失

即使脚本能运行，也可能因SELinux限制无法设置系统属性。日志中会出现：

avc: denied { write } for name="test.boot.script.executed" ...

此时需要添加属性访问权限：

在test_service.te中增加：

# 允许设置特定属性 allow test_service system_prop:property_service_set test.boot.script.executed;

或者更宽松的方式（仅限调试）：

# 允许设置所有系统属性（不推荐生产环境） allow test_service system_prop:property_service_set *;

4.4 log命令失败？缺少socket连接权限

如果脚本中调用log输出日志，可能会报错：

avc: denied { connectto } for path="/dev/socket/logdw" ...

需添加日志写入权限：

# 允许向logd写入日志 allow test_service logd_socket:sock_file write; allow test_service logd:unix_stream_socket connectto;

5. 最佳实践与工程建议

5.1 分离脚本与策略，提升可维护性

建议将脚本、.rc配置、SELinux策略分别存放于不同目录，结构清晰：

device/ └── company/ └── device/ ├── init.test.sh ├── init.device.rc └── sepolicy/ ├── test_service.te └── file_contexts

避免将所有内容混杂在一个文件夹中。

5.2 使用permissive模式辅助调试

在开发阶段，可临时将域设为宽容模式：

permissive test_service;

此时SELinux会记录拒绝行为但不阻止执行，极大方便调试。上线前务必移除！

5.3 避免直接修改init.rc

原始init.rc属于AOSP核心文件，直接修改会影响升级兼容性。应使用设备专属的init.<name>.rc并通过import引入：

import /init.device.rc

5.4 利用属性控制执行时机

可通过属性控制脚本是否运行，增强灵活性：

#!/system/bin/sh if [ "$(getprop ro.debuggable)" == "1" ]; then setprop test.boot.script.executed 1 fi

或结合on property:触发：

on property:test.trigger.start=1 start test_boot_script

6. 总结

6.1 核心要点回顾

1. 脚本路径与解释器必须准确：使用/system/bin/sh作为shebang。
2. init服务需明确定义seclabel：这是SELinux权限的起点。
3. file_contexts必须匹配文件路径：正则表达式要精确，注意转义。
4. TE文件需声明init_daemon_domain：允许init域派生新服务。
5. 属性、日志等操作需额外授权：SELinux默认拒绝一切未声明行为。

6.2 工程化落地建议

• 开发阶段开启permissive模式快速定位问题
• 使用dmesg和logcat联合分析AVC拒绝日志
• 尽量避免allow all式宽泛授权，坚持最小权限原则
• 构建自动化验证流程，确保每次变更后脚本能稳定执行

掌握这些方法后，SELinux不再是神秘黑盒，而是保障系统安全的有力工具。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。