解决 系统升级后Selinux的file_context指定的目录或者文件域变成unlabeled

最近遇到一个selinux相关问题，相关的denied打印如下：

avc: denied { write } for name="/" dev="mmcblk0pxx" ino=2 scontext=u:r:AAAA:s0 tcontext=u:object_r:unlabeled:s0 tclass=dir permissive=0

avc: denied { create } for pid=1886 comm="xxxxx" name=aaa" scontext=u:AAAA:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0

之前指定的/aaa/bbb目录下的文件域为XXX_XXX突然全部变成unlabeled。

unlabeled的标签是系统没有指定的目录就是unlabeled。尝试把出现的denied规则加到te文件里？too yong to naive.

Google能随随便便让进程去建unlabeled ？在external/sepolicydomain.te文件中有如下neverallow规则：

# Do not allow any domain other than init or recovery to create unlabeled files.
neverallow { domain -init -recovery } unlabeled:dir_file_class_set create;

凡是过CTS的娃娃都应该明白这意味着什么，不能随便加！而且neverallow 规则不能修改，否则CTS会有fail项。

Google不让改怎么办？问Google吧！

Google到相关的资料都指向一个原因：系统可能做过OAT升级到时系统分区被破坏，selinux属性丢失

https://marc.info/?l=seandroid-list&m=142072965016559&w=2

咨询了报问题的同事，出问题的机器没有做过OAT升级/(ㄒoㄒ)/~~。但是还是怀疑和分区被破坏有关系。

接着分析：

1.拷贝出来板子的/file_contexts文件，发现指定/aaa/bbb目录的域确实是XXX_XXX。

2.实验把/aaa/bbb目录指定为CCC_CCC重新烧boot.img发现域还是没有改变。

使用命令restorecon -r /aaa/bbb指定的CCC_CCC域起作用，此时怀疑系统有备份file_contexts的属性到某个地方。

3.紧接着查到系统里有把file_contexts的指定设置到系统的分区镜像里。用dd命令拷贝出来/dev/block/分区镜像。查看多了unlabeled的字段。

最后联想到最近有同事做数据保护工作。咨询了同事在/aaa/bbb分区因为写数据掉电或者其他情况被破坏掉后，他会使用make_ext4fs重新格式化分区，但是格式化话后没有回复selinux的域指定。而系统在升级时不会去升级/aaa/bbb分区，系统每次起来都会读一句坏了的分区中保存的/file_contexts。导致出现u:object_r:unlabeled:s0 问题。

解决方法是在数据保护格式化分区后重新调用一次selinux_android_restorecon方法回复selinux属性。

关于selinux_android_restorecon 参考文章：http://blog.csdn.net/l173864930/article/details/17232547