背景
在mediaservice中读取设备节点/dev/sst_storage失败，通过log发现没有权限。尝试chomd 777设置设备节点权限，发现在代码中还是无法获取到权限打开和读取。通过网上资料查询获知可能是SELinux策略导致的。
了解权限管理机制
权限管理机制介绍
SEAndroid 是SELinux 在Android 上面的一个移植。SELinux 是Linux上系统保护机制，SELinux 全称 Security Enhanced Linux (安全强化 Linux)，是MAC (Mandatory Access Control，强制访问控制系统)的一个实现。 其目的在于明确的指明某个进程可以访问哪些资源(文件、网络端口等)。
Android系统基于Linux实现。针对传统Linux系统，NSA开发了一套安全机制SELinux，用来加强安全性。然而，由于Android系统有着独特的用户空间运行时，因此SELinux不能完全适用于Android系统。为此，NSA同Google一起针对Android系统，在SELinux基础上开发了 SEAndroid。 遇到这类问题的解决方法 在Android
7.0上，因为采取了SEAndroid/SElinux的安全机制，即使拥有root权限，或者对某内核节点设置为777的权限，仍然无法在JNI层访问。Google 默认禁止app , 包括system app, radio app 等直接写/sys 下面的文件, 认为这个是有安全风险的。如果直接放开SELinux 权限, 会导致CTS 无法通过.
通常遇到此类情况，你有两种做法:
(1). 通过system_server 或者 init 启动的service 读写, 然后app 通过binder/socket 等方式连接APP 访问. 此类安全可靠, 并且可以在service 中做相关的安全审查, 推崇这种方法.
(2). 修改对应节点的SELinux Security Label, 为特定的APP, 如system app, radio,bluetooth 等内置APP开启权限, 但严禁为untrsted app 开启权限. 具体的做法下面以 system app 控制/sys/class/leds/lcd-backlight/brightness 来说明.本文主要采用这个做法来解决。
解决方案
两个命令确定问题是否与SELinux相关
- 1、命令：setenforce 0
- 2、命令：getenforce确认SELinux 是否正确关闭，如下图则说明关闭了。
如下图，则说明没有关闭
关闭手机的 SELINUX 机制，如果问题还能复现，那么此问题就与 SELinux 不相关，或者相关 但是还与别的机制相关，比如还与 Linux 自主访问控制（DAC）有关。
修改对应的策略文件
1、分解log
重点log：
avc: denied { read } for name=“mmcblk0p12” dev=“tmpfs” ino=7011
scontext=u:r:mediaserver:s0 tcontext=u:object_r:block_device:s0
tclass=blk_file permissive=0
对应的分解：
avc: denied { 操作权限 } for pid=7201 comm=“进程名” scontext=u:r:源类型:s0
tcontext=u:r:目标类型:s0 tclass=访问类型 permissive=0
2、添加对应的权限
在相应源类型.te 文件，添加如下格式的一行语句：(结尾别忘了分号) 格式：allow 源类型 目标类型:访问类型 {操作权限};
如上log：
在system/sepolicy目录下找到对应 mediaserver.te 文件添加权限语句：allow mediaserver
block_device:blk_file { read };
添加权限后还是报错。如上图，open权限不够导致失败，又将open权限加上。
文件添加权限语句：
allow mediaserver block_device:blk_file { open read };
问题就解决了。
注意，如果你的*.te文件跟我目录不一致，可以尝试用find命令查找一下。
总结
是时候总结一波了。解决这种问题三个步骤。
- 1、确定是否跟SELinux策略有关，如果没有关系直接进入3步骤。有关系往下走2步骤。
- 2、修改SELinux相关文件。
- 3、最后关键的一步，是时候 来一波关注 了，搞定。
如果还有什么不懂的。可以关注小编的公众号，里面有很多大牛，以及往期精彩文章替你答疑。
