我的音频HAL中有一个unix socket守护进程，我需要从我的应用程序连接到该守护进程。
我得到SELinux拒绝登录如下：
08-08 10:38:01.939 2622-2622/com.xxx.xxx.xxx W/ksetsdk.xxx: type=1400 audit(0.0:511): avc: denied { connectto } for path=0023xxx scontext=u:r:system_app:s0 tcontext=u:r:audioserver:s0 tclass=unix_stream_socket permissive=0
即使我的应用程序使用平台密钥签名，也会打印出来，安装在system.img中并作为系统运行：
root@hikey:/ # ps | grep xxx
system 2619 1893 1561788 86956 SyS_epoll_ 0000000000 S com.xxx.xxx.xxx
root@hikey:/ # ps -Z | grep xxx
u:r:system_app:s0 system 2619 1893 1561788 86736 SyS_epoll_ 0000000000 S com.xxx.xxx.xxx
root@hikey:/ #
我已经按照以下方式添加了SEPolicy：
auditallow system_app audioserver:unix_stream_socket { ioctl read getattr write setattr lock append bind connect getopt setopt shutdown connectto };
任何人都可以指导我错过的内容吗？ AOSP SEPolicy中是否有任何与此相矛盾的规则？我如何让它工作？
答案 0 :(得分：1)
我的构建aosp和更改SEPolicy规则一定存在一些同步问题。
我做了更详尽的测试，发现：
（1）当app由平台密钥签名，并在manifest中请求系统uid时，它以system_app运行并遵循以下规则：
auditallow system_app audioserver:unix_stream_socket { connectto };
（2）当应用程序由平台密钥签名但未在清单中请求系统uid时，它将作为platform_app运行，但遵循规则不工作：
auditallow platform_app audioserver:unix_stream_socket { connectto };
（3）如果应用程序未通过平台密钥签名，则它将作为priv_app运行，并且遵循规则不工作：
auditallow priv_app audioserver:unix_stream_socket { connectto };
当我测试时，我必须把AOSP中建立的规则混淆了。
对于我来说，为什么priv_app或platform_app不起作用仍然是个谜，但system_app会有类似的规则。