本文共 1678 字，大约阅读时间需要 5 分钟。
一、案例
我们举个案例，比如recovery升级中，碰到这个的log
- 01-01 08:03:22.410000 217 217 W applypatch: type=1400 audit(0.0:16): avc: denied { read } for name="mmcblk0p15" dev="tmpfs" ino=3364 scontext=u:r:install_recovery:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0
说明install_revovery没有block_device的权限。
而在原生的domain.te文件中，明确domain中是没有对block_device的读写权限，除了recovery vold等。
- neverallow { domain -kernel -init -recovery -vold -uncrypt -emsd -rild -radio_config} block_device:blk_file { open read write };
二、方法1（后续cts测试会有问题）
那我们如何是好呢，可以在上面这句nevera中把install_recovery也减去，然后再install_recovery.te中再加入相应的allow，这个时候编译就不会报错了。
但是这个方法，后续会在cts测试的时候过不了。
因此我们不能采取这种方法。
三、方法2
所以我们得想别的方法，我们发现在domain.te中同样有下面这么一句，是可以允许install_recovery去写recover_block_device的权限。
- ./domain.te:354:neverallow { domain -install_recovery -recovery } recovery_block_device:blk_file write;
于是我们再去查block_device 和 recover_block_device
- type recovery_block_device, dev_type;
- type block_device, dev_type;
这两个的类型一致。
但我们再看file_contexts，看下文件安全上下文
- /dev/block(/.*)? u:object_r:block_device:s0
定义的dev/block下面的文件都是block_device，而recover_block_device是没有定义的。那我们也能不能定义我们要操作的文件为recover_block_device类型。
答案肯定是可以的。
- /dev/block(/.*)? u:object_r:block_device:s0
- /dev/block/dm-[0-9]+ u:object_r:dm_device:s0
- /dev/block/loop[0-9]* u:object_r:loop_device:s0
- /dev/block/vold/.+ u:object_r:vold_device:s0
- /dev/block/ram[0-9]* u:object_r:ram_device:s0
我们也可以自己定义自己的文件为recover_block_device类型，感觉这是给大家预留的。
具体实现就不说了，因为具体要操作什么文件不是太清楚，这只是一个log而已。
最后我们只要在install_recovery.te中加入下面权限就可以了。
- allow install_recovery recover_block_device:blk_file { open read write };
这样install_recovery就有了目标文件的open read write权限了。
转载地址：http://cjngi.baihongyu.com/