折腾：
【未解决】安卓项目rcsjta的core运行报错：libc Access denied finding property ro.vendor.df.effect.conflict
期间，rcsjta的core的apk调试报错：
2020-08-04 16:05:39.102 6396-6396/com.gsma.rcs W/com.gsma.rcs: type=1400 audit(0.0:526384): avc: denied { read } for name="u:object_r:vendor_displayfeature_prop:s0" dev="tmpfs" ino=16384 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:vendor_displayfeature_prop:s0 tclass=file permissive=0
2020-08-04 16:05:39.113 6396-6396/com.gsma.rcs E/libc: Access denied finding property "ro.vendor.df.effect.conflict"从贴子：
此处注意到，前面一个错误是avc: denied：
W ssProcessingApp: type=1400 audit(0.0:93822): avc: denied { read } for name="u:object_r:vendor_displayfeature_prop:s0" dev="tmpfs" ino=27787 scontext=u:r:untrusted_app_27:s0:c57,c256,c512,c768 tcontext=u:object_r:vendor_displayfeature_prop:s0 tclass=file permissive=0而此处我这里本身也是：
2020-08-04 16:05:39.102 6396-6396/com.gsma.rcs W/com.gsma.rcs: type=1400 audit(0.0:526384): avc: denied { read } for name="u:object_r:vendor_displayfeature_prop:s0" dev="tmpfs" ino=16384 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:vendor_displayfeature_prop:s0 tclass=file permissive=0
2020-08-04 16:05:39.113 6396-6396/com.gsma.rcs E/libc: Access denied finding property "ro.vendor.df.effect.conflict"这里也是 avc: denied
2020-04-17 16:58:23.783 564-564/? E/SELinux: avc: denied { find } for interface=vendor.qti.hardware.servicetracker::IServicetracker sid=u:r:system_server:s0 pid=1587 scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_hwservice:s0 tclass=hwservice_manager permissive=0
2020-04-17 16:58:23.804 22933-22933/? E/libc: Access denied finding property "ro.vendor.df.effect.conflict"2020-04-02 11:16:50.826 568-568/? E/SELinux: avc: denied { find } for interface=vendor.qti.hardware.servicetracker::IServicetracker sid=u:r:system_server:s0 pid=1625 scontext=u:r:system_server:s0 tcontext=ubject_r:default_android_hwservice:s0 tclass=hwservice_manager permissive=0
2020-04-02 11:16:50.860 674-14413/? E/ResolverController: No valid NAT64 prefix (109, <unspecified>/0)
2020-04-02 11:16:50.947 14392-14392/? E/libc: Access denied finding property "ro.vendor.display.type"
2020-04-02 11:16:51.080 14392-14392/? E/libc: Access denied finding property "ro.vendor.df.effect.conflict"那换去搜：
avc denied read for name
It’s depends of SELinux restrictions. You cannot do so much to avpoid it.
看来是Android此处的安全方面的限制了
没法规避，也做不了啥
To avoid it you should rebuild the ROM after changed specific files about SELinux where you have to add your App in the “trusted zone”.
果然是：
SELinux是Google从android 5.0开始，强制引入的一套非常严格的权限管理机制，主要用于增强系统的安全性。
然而，在开发中，我们经常会遇到由于SELinux造成的各种权限不足，即使拥有“万能的root权限”，也不能获取全部的权限
再去分析此处的：
type=1400 audit(0.0:526384): avc: denied { read } for name="u:object_r:vendor_displayfeature_prop:s0" dev="tmpfs" ino=16384 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:vendor_displayfeature_prop:s0 tclass=file permissive=0- avc: denied { read } for
- denied表示：没权限，拒绝访问
- name=”u:object_r:vendor_displayfeature_prop:s0″
- 看起来像是要具体访问的东西
- vendor_displayfeature_prop
- 其中有个vendor
- 和后续属性报错：libc: Access denied finding property “ro.vendor.df.effect.conflict” 明显就是有关系的
- 无法读取ro.vendor.df.effect.conflict
- 是因为没有权限
- dev=”tmpfs”
- 信息放在tmpfs上的？
- ino=16384
- 像是 inode 的number ，linux文件系统内部的节点？
- scontext=u:r:untrusted_app_25:s0:c512,c768
- scontext = security context ？
- untrusted_app_25
- untrusted app：表示此处是不可信的app
- 所以拒绝访问
- 含义：谁缺少权限
- tcontext=u:object_r:vendor_displayfeature_prop:s0
- 和前面的name的值对应：u:object_r:vendor_displayfeature_prop:s0
- 总之都是vendor的显示相关参数和属性
- 含义：对哪个文件缺少权限
- tclass=file
- file类型？
- 含义：什么类型的文件
- permissive=0
- 0表示拒绝 没权限
-》untrusted_app_25 缺少对vendor_displayfeature_prop:s0类型的 file 缺少read权限
“解决原则是：缺什么权限补什么，一步一步补到没有avc denied为止。
解决权限问题需要修改的权限文件如下位置，以.te结尾
A：Android/devicesoftwinner/astar-common/sepolicy/*.te
B：Android/external/sepolicy/*.te
其中，A是对B的overlay（覆盖），能在A修改的尽量在A修改，尽量避免修改B，修改B可能会导致CTS fail问题，修改A不会影响CTS测试。”
去小米9中用ES文件浏览器去看看是否有上述2个文件
不过突然想到：
Android Studio中能否有编辑和查看安卓真机中的文件？
结果不是，只是打开了AVD窗口。
还是去ES吧
结果搜不到：sepolicy
“解决方法：在上文A位置，找到kernel.te这个文件，加入以下内容：
allow kernel block_device:blk_file write;
make installclean后重新编译，刷boot.img才会生效。”
此处放弃。因为要重新编译ROM刷ROM才可以。
此处没有：重新编译小米MIUI的权限和机会。
根据这个信息，一般的做法是 在 untrusted_app_25.te 中增加 allow untrusted_app_25 video_device:chr_file { read ioctl };
去找找是否有：untrusted_app_25.te
找不到。
“ From the top of the AOSP directory issue these commands, (for more info read- https://source.android.com/security/selinux/validate)
adb pull /sys/fs/selinux/policy adb logcat -b all -d | audit2allow -p policy
it should output something like this
#============= bootanim ==============
allow bootanim rootfs:lnk_file getattr;
Now navigate to the sepolicy directory of your device’s folder(TOP/device/your_device/sepolicy) and add the allow rule returned above, in the respective te file.
Here I add this (allow bootanim rootfs:lnk_file getattr; ) line to (bootanim.te) file.”
好像是可以去通过adb去操作policy的
android開發基礎（五）- avc: denied解決範例 – 不及格研究室
https://blog.twshop.asia/android開發基礎（五）-avc-denied解決範例/
所以先去研究搞清楚：
adb pull /sys/fs/selinux/policy
“验证 SELinux
Android 强烈建议 OEM 全面测试其 SELinux 实现。制造商在实现 SELinux 时，应先在一组测试设备上实施新政策。
实施新政策后，您可以通过执行 getenforce 命令来确认 SELinux 在设备上的运行模式是否正确。
该命令会输出全局 SELinux 模式：强制或宽容。要确定每个域的 SELinux 模式，您必须检查相应的文件，或运行带有相应 (-p) 标记的最新版 sepolicy-analyze（位于 /platform/system/sepolicy/tools/ 中）。
读取拒绝事件
检查是否有错误，错误会以事件日志的形式传给 dmesg 和 logcat，并可在设备上从本地查看。制造商应先检查这些设备上传给 dmesg 的 SELinux 输出并优化设置，然后再在宽容模式下公开发布，最后切换到强制模式。SELinux 日志消息中包含“avc:”字样，因此可使用 grep 轻松找到。您可以通过运行 cat /proc/kmsg 来获取当前的拒绝事件日志，也可以通过运行 cat /sys/fs/pstore/console-ramoops 来获取上次启动时的拒绝事件日志。”
官网解释的很清楚了。
内部是实现了SELinux，且希望OEM厂商自己实现对应的策略并测试好。
“根据这些输出内容，制造商可以轻松发现系统用户或组件违反 SELinux 政策的行为。然后，制造商便可更改相应软件和/或 SELinux 政策，以防范此类恶意行为。
具体来说，这些日志消息会指明在强制模式下哪些进程会失败以及失败原因。示例如下
avc: denied { connectto } for pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket该输出的解读如下：
- * 上方的 { connectto } 表示执行的操作。根据它和末尾的 tclass (unix_stream_socket)，您可以大致了解是对什么对象执行什么操作。在此例中，是操作方正在试图连接到 UNIX 信息流套接字。
- * scontext (u:r:shell:s0) 表示发起相应操作的环境，在此例中是 shell 中运行的某个程序。
- * tcontext (u:r:netd:s0) 表示操作目标的环境，在此例中是归 netd 所有的某个 unix_stream_socket。
- * 顶部的 comm=”ping” 可帮助您了解拒绝事件发生时正在运行的程序。在此示例中，给出的信息非常清晰明了。”
所以很清楚了。
去试试这个：
adb shell su root dmesg | grep 'avc: '
结果：
~ adb shell su root dmesg | grep 'avc: ' /system/bin/sh: su: inaccessible or not found
此处小米9中，不允许su，没权限。
另外举例：
<5> type=1400 audit: avc: denied { read write } for pid=177
comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
tcontext=u:object_r:kmem_device:s0 tclass=chr_file以下是此拒绝事件的关键元素：
- * 操作 – 试图进行的操作会使用括号突出显示：read write 或 setenforce。
- * 操作方 – scontext（来源上下文）条目表示操作方；在此例中为 rmt_storage 守护进程。
- * 对象 – tcontext（目标上下文）条目表示对哪个对象执行操作；在此例中为 kmem。
- * 结果 – tclass（目标类别）条目表示操作对象的类型；在此例中为 chr_file（字符设备）。
那去试试：
adb pull /sys/fs/selinux/policy
输出：
~ adb pull /sys/fs/selinux/policy /sys/fs/selinux/policy: 1 file pulled. 20.8 MB/s (774382 bytes in 0.036s)
好像当前文件夹中有个：policy，是70多KB
~ ll 。。。 -rw-r--r-- 1 xxx CORP\Domain Users 756K 8 4 18:10 policy
然后去分析看看
结果是二进制文件
然后：
xxx@xxx ~/dev/xx/RCS/rcsjta/for_debug/XiaoMi9 ll total 1520 -rw-r--r-- 1 xxx CORP\Domain Users 756K 8 4 18:10 policy
继续，结果报错：
先去解决：
【未解决】Mac中找不到audit2allow：zsh command not found audit2allow
感觉是：
这个命令是需要放到手机中操作的？
那去试试：
pull之前的te文件
不过在此之前先去试试
adb root adb pull /sys/fs/selinux/policy
提到的root的权限
adb root adbd cannot run as root in production builds
类似的：
adb shell setenforce 0 setenforce: Couldn't set enforcing status to '0': Permission denied
肯定也没权限。
去尝试：
【未解决】Mac中找不到audit2allow：zsh command not found audit2allow
但是无法将解决。
目前Mac中无法安装audit2allow
所以也就无法继续运行：
adb logcat -b all -d | audit2allow -p policy
只能放弃。
不过，还是先去试试前面的命令的输出：
adb logcat -b all -d
会输出一堆堆的log
太多了。
至此，暂时放弃解决这个问题。
【总结】
此处的的logcat看到rcsjta的core的log：
2020-08-04 16:05:39.102 6396-6396/com.gsma.rcs W/com.gsma.rcs: type=1400 audit(0.0:526384): avc: denied { read } for name="u:object_r:vendor_displayfeature_prop:s0" dev="tmpfs" ino=16384 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:vendor_displayfeature_prop:s0 tclass=file permissive=0
2020-08-04 16:05:39.113 6396-6396/com.gsma.rcs E/libc: Access denied finding property "ro.vendor.df.effect.conflict"其中第二条：
E/libc: Access denied finding property "ro.vendor.df.effect.conflict"
意思是：没有权限读取ro.vendor.df.effect.conflict这个属性
原因：没有权限读取。
具体情况：第一条log显示的。
type=1400 audit(0.0:526384): avc: denied { read } for name="u:object_r:vendor_displayfeature_prop:s0" dev="tmpfs" ino=16384 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:vendor_displayfeature_prop:s0 tclass=file permissive=0- Action=操作：read
- Actor=操作方=scontext=source context=来源上下文：untrusted_app_25
- Object=对象=tcontext=target context=目标上下文：vendor_displayfeature_prop
- 注：
- 对应着后续的ro.vendor.df.effect.conflict
- object_r=object read=读取目标（的属性）？
- Result=结果=tclass=target class=目标类别=操作对象的类型：file
- permissive=宽容模式：0
- -》0：表示不允许
- 所以此处是属于 非宽容模式= 强制模式？
- 背景知识：
- selinux有2种模式
- permissive宽容模式
- enforcing强制模式
- 安卓设备（系统）启动时，（内核参数中）可以设置对应的模式：
- androidboot.selinux=permissive
- androidboot.selinux=enforcing
翻译成人话就是：
untrusted_app_25 想要对于 file 类型的 vendor_displayfeature_prop 去 read
（但是被Android的SELinux拒绝denied了，原因是：没有权限
根本原因是：当前不是宽容模式
-》反推出：由于之前的SELinux中的权限配置，使得此处
untrusted_app_25 没有read这个vendor_displayfeature_prop的权限
解决思路：
（可能1）如果有内核操作权限
启动时，加内核参数：
androidboot.selinux=permissive
可以暂时允许权限，此处去读取参数，去调试后续代码。
（可能2）如果电脑中能安装audit2allow
理论上可以继续参考：
和：
去操作：
adb pull /sys/fs/selinux/policy adb logcat -b all -d | audit2allow -p policy
以及其他帖子如
去给安卓系统中增加或找到已有te文件，此处的
untrusted_app_25.te
加上：
allow untrusted_app_25 vendor_displayfeature_prop:file read;
但是：
此处既没有（小米9安卓10系统的）内核操作权限
也也无法（在此处Mac中）安装audit2allow
所以只能放弃此路。
相关名词：
- fc=file context
- te=type enforcement
后记：
回复了帖子
转载请注明：在路上 » 【无法解决】安卓项目rcsjta的core运行报错：type 1400 audit avc denied read for name object_r vendor_displayfeature_prop s0 dev tmpfs scontext tcontext tclass file permissive 0